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

[Robbin Ehn]

On Thu, 16 Feb 2023 08:38:42 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> 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. (instead of adding Compile_lock to all places)
> 
> 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

This pull request has now been integrated.

Changeset: c183fce9
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c183fce9543ca15f5db632babecdb7797d0745e4
Stats:     449 lines in 24 files changed: 215 ins; 109 del; 125 mod

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

Reviewed-by: eosterlund, dcubed, coleenp

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

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