[12] RFR: 8215555: TieredCompilation C2 threads can excessively block handshakes

[Robbin Ehn]

Thanks for fixing Claes!

/Robbin

On 12/20/18 11:47 AM, Claes Redestad wrote:
> Hi,
> 
>   please review this trivial fix to a somewhat complex startup
> regression with tiered compilation...
> 
> Let me try to explain (Robbin can correct me if I'm wrong on some
> of the details below)
> 
> Basically, since 12-b14 the NMethod sweeper thread attempts to perform
> stack scanning as soon as it's initialized, which means it needs to
> safepoint/handshake with other threads.
> 
> One of the C2 threads started right before is always busy compiling
> stub code when this happen, an operation that takes ~10-12 ms and is
> done in VM mode (typically compiler threads execute compilations in
> native mode, which mean handshakes will be handled by the VM thread
> if a compiler thread is busy compiling: long-running compilations
> typically *shouldn't* delay handshakes).
> 
>   Since it's running in VM mode, the handshake can't be delegated to
> the VM thread as would normally happen. This means the NMethod sweeper
> thread has to spin wait until the stub generation has finished, at
> which point the handshake can complete. This effectively wastes ~50
> million cycles on my machine, but will vary on hardware.
> 
>   The chosen solution is to instruct the NMethod Sweeper thread not to
> sweep on first run by initializing _should_sweep to false. The initial
> sweep that we'd skip by doing this is rather pointless since it's
> highly unlikely that there can ever exist an nmethod the sweeper can do
> anything with this early.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8215555/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215555
> 
> Testing: tier1-3, verified a significant startup improvement
> 
> Thanks!
> 
> /Claes