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

TieredCompilation C2 threads can excessively block handshakes

    XMLWordPrintable

Details

    • b26

    Backports

      Description

        ThreadLocalHandshakes introduce a diagnostic flag to abort the VM if a handshake takes more than some set time:

        java -XX:+UnlockDiagnosticVMOptions -XX:HandshakeTimeout=20 -version

        Setting this to a low value, like 5 or 10 (ms) makes the VM likely to abort on startup on my machine:

        $ java -XX:+UnlockDiagnosticVMOptions -XX:HandshakeTimeout=10 -version
        #
        # A fatal error has been detected by the Java Runtime Environment:
        #

        This does not happen with -Xint, -XX:-TieredCompilation or even -XX:TieredStopAtLevel=1, all these get through startup just fine even with -XX:HandshakeTimeout=1.

        This indicates there's a handshake blocked by a compiler thread for an excessive amount of time, which consistently happen during startup. This appears to be a major contributor to increased work during startup since the handshake is causing excessive spin.

        This turns out to be due to interaction between the NMethod sweeper thread - which is started very early and attempts early handshakes in NMethodSweeper::do_stack_scanning - and the stub code generation in OptoRuntime::generate(ciEnv* env) which compiles code in VM mode for ~10ms. Moving this to native mode resolves the issue, but a simpler and safer fix is to instruct the NMethod Sweeper thread not to do the scan on first run.

        Attachments

          Issue Links

            Activity

              People

                redestad Claes Redestad
                redestad Claes Redestad
                Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: