RFR(XL): 8185640: Thread-local handshakes

Erik Österlund erik.osterlund at oracle.com
Tue Oct 17 15:30:30 UTC 2017

Hi Robbin,

Looks fantastic.


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

More information about the hotspot-dev mailing list