RFR(XL): 8185640: Thread-local handshakes

[Robbin Ehn]

Hi all,

Update after re-base with new atomic implementation:
http://cr.openjdk.java.net/~rehn/8185640/v1/Atomic-Update-Rebase-3/
This goes on top of the Handshakes-2.

Let me know if you want some other kinds of webrevs.

I would like to point out that Mikael Gerdin and Erik Österlund also are 
contributors of this changeset.

Thanks, Robbin

On 2017-10-11 15:37, Robbin Ehn wrote:
> Hi all,
> 
> Starting the review of the code while JEP work is still not completed.
> 
> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640
> 
> This JEP introduces a way to execute a callback on threads without performing a 
> global VM safepoint. It makes it both possible and cheap to stop individual 
> threads and not just all threads or none.
> 
> Entire changeset:
> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/
> 
> Divided into 3-parts,
> SafepointMechanism abstraction:
> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/
> Consolidating polling page allocation:
> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/
> Handshakes:
> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/
> 
> A handshake operation is a callback that is executed for each JavaThread while 
> that thread is in a safepoint safe state. The callback is executed either by the 
> thread itself or by the VM thread while keeping the thread in a blocked state. 
> The big difference between safepointing and handshaking is that the per thread 
> operation will be performed on all threads as soon as possible and they will 
> continue to execute as soon as it’s own operation is completed. If a JavaThread 
> is known to be running, then a handshake can be performed with that single 
> JavaThread as well.
> 
> The current safepointing scheme is modified to perform an indirection through a 
> per-thread pointer which will allow a single thread's execution to be forced to 
> trap on the guard page. In order to force a thread to yield the VM updates the 
> per-thread pointer for the corresponding thread to point to the guarded page.
> 
> Example of potential use-cases:
> -Biased lock revocation
> -External requests for stack traces
> -Deoptimization
> -Async exception delivery
> -External suspension
> -Eliding memory barriers
> 
> All of these will benefit the VM moving towards becoming more low-latency 
> friendly by reducing the number of global safepoints.
> Platforms that do not yet implement the per JavaThread poll, a fallback to 
> normal safepoint is in place. HandshakeOneThread will then be a normal 
> safepoint. The supported platforms are Linux x64 and Solaris SPARC.
> 
> Tested heavily with various test suits and comes with a few new tests.
> 
> Performance testing using standardized benchmark show no signification changes, 
> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not 
> statistically ensured). A minor regression for the load vs load load on x64 is 
> expected and a slight increase on SPARC due to the cost of ‘materializing’ the 
> page vs load load.
> The time to trigger a safepoint was measured on a large machine to not be an 
> issue. The looping over threads and arming the polling page will benefit from 
> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) 
> which puts all JavaThreads in an array instead of a linked list.
> 
> Thanks, Robbin