RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all platforms

[Robbin Ehn]

Hi all, please consider.

The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.

Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts,
the fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked.

This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.

This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
Secondly it moves handshakes part out of the Compile_lock where it is possible.

Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.

It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.

Thanks, Robbin

-------------

Commit messages:
 - Fixed WS
 - Deopt scopes

Changes: https://git.openjdk.org/jdk/pull/12585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300926
  Stats: 380 lines in 24 files changed: 192 ins; 91 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/12585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12585/head:pull/12585

PR: https://git.openjdk.org/jdk/pull/12585