Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8255381

com/sun/jdi/EATests.java should not suspend graal threads

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b29
    • CPU:
      x86_64
    • OS:
      windows

      Backports

        Description


        Symptom
        -------

        The following test failed in the JDK16 CI because it reached the timeout of 1200 seconds:

        com/sun/jdi/EATests.java#id1

        Here's a snippet from the log file:

        ###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!


        ###(Debugger) Debuggee Stack:

        frame[0]: EAMaterializeLocalAtObjectPollReturnReturnTarget.dontinline_brkpt_return_Integer() (bci:2)
        frame[1]: EAMaterializeLocalAtObjectPollReturnReturnTarget.dontinline_testMethod() (bci:41)
        frame[2]: EATestCaseBaseTarget.run() (bci:64)
        frame[3]: EATestsTarget.main(java.lang.String[]) (bci:43)

        ###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!


        ###(Debugger) Debuggee Stack:

        frame[0]: EAMate
        result: Error. Agent error: java.lang.Exception: Agent 17 timed out with a timeout of 1200 seconds; check console log for any additional details


        The test repeated this bit over and over:

        ###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!

        Analysis
        --------

        The test was executed with graal enabled as jvmci client.

        The test cases make use of the TestScaffold in a way that all threads, including
        graal threads, are suspended when one thread reaches a breakpoint and
        subsequentially it resumes just the main thread. This is problematic: graal
        threads remain suspended and the main thread blocks because of -Xbatch when it
        calls a method that reaches the compile threshold. Note that, if graal is
        enabled, -Xbatch won't make a java thread wait unconditionally until a
        compilation task is completed. Instead it will continue after a given time
        without progress [1].

        This is the cause for (a) timeouts (b) a test case's main test methods are not
        always compiled after warm-up.

        [1] CompileBroker::wait_for_jvmci_completion() is with timeout
            https://github.com/openjdk/jdk/blob/fbdc1877e241552755ea208b890029e60a8df08c/src/hotspot/share/compiler/compileBroker.cpp#L1691

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                rrich Richard Reingruber
                Reporter:
                dcubed Daniel Daugherty
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: