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

[Claes Redestad]

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