Due to safepoints and VM operations, as well as other optimizations that JIT can do if you allow for signal management.
The JVM sometimes has to perform some operations that require it to pause execution around the world ("stop the world"), for example, some large-scale garbage collections, hot reloads, or internal recompiling classes, etc. To do this, he must make sure that all running threads immediately fall into the barrier and pause, perform the operation, and then release the threads.
One method that HotSpot uses (and probably other JVMs) to implement safepoints is the clever abuse of segfaults: it creates a memory page that is not actually used for any data, and then each thread periodically tries to read from this page, When no VM operation is required, reading is performed with very low overhead, and the stream simply continues to run.
When the JVM needs to perform a virtual machine operation, this invalidates this memory page. The next time each thread falls into safepoint, it now calls segfault , which allows the JVM to regain control of this thread execution; it runs until the VM operation is completed, resets the sentinel page and restarts all threads.
When you turn off SIGSEGV processing, the JVM must use other methods to synchronize secure points, which are less efficient than delegating built-in processor protection.
In addition, the JVM does some serious profiling magic (essentially the same as a processor branch predictor). One of the optimizations that he uses is that if he finds that a particular zero check is almost never zero, it returns a check and relies on segfault (expensive, but in rare cases) to catch zero. This optimization also requires special SIGSEGV processing.
chrylis
source share