RFR: 8215555: TieredCompilation C2 threads can excessively block handshakes
nils.eliasson at oracle.com
Thu Dec 20 11:00:58 UTC 2018
I might add that Robbin has a patch that makes the stub generation
happen in native, like normal compilations. So we are fixing the problem
from both ends.
On 2018-12-20 11:47, Claes Redestad wrote:
> 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
More information about the hotspot-compiler-dev