JIT compilers in current Hotspot are compiling the code while being in native state. So if there is a running compilation, it does not block shutdown naturally. The shutdown code has cooperative mechanism to coordinate shutdown of compiler threads. Shutdown code sets the `CompilerBroker::should_block`, and compilers are regularly checking it with `CompilerBroker::maybe_block`. When shutdown is pending, the running compiler threads would eventually hit that maybe_block, block at transition to VM state, and that would allow shutdown to proceed.

Compilers are usually checking with `CompilerBroker::maybe_block` fairly often, and so they are very quick to respond to the blocking request. Yet, the shutdown code waits for 10ms on every attempt. Note that since we set `should_block` and immediately roll to checking the threads state, we are almost always guaranteed to outpace the compiler thread response for the first time. So we proceed to wait for 10ms, if _any_ active compilation is running, even if it can respond to request almost immediately.

This contributes considerably to end-to-end Java execution time, especially with smaller workloads. This regularly happens with benchmarks that target Leyden, where heavy compilation happens right until the shutdown.

It looks to me the core of this code was not touched since OpenJDK inception, and we might need to polish it for the new realities.

There is a second part of the story, and that is making sure the compilers _do_ check for blocking often: JDK-8350083.