RFR(XL): 8185640: Thread-local handshakes

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Oct 18 20:44:28 UTC 2017

This looks really nice.  A few minor comments.


   51 // or the JavaThread it self.

typo, "itself"

Thank you for adding these comments.  I think they're just right in 
length and detail in the header.


The protocol in HandshakeState::process_self_inner and cancel_inner is:

     if (op != NULL) {

But in HandshakeState::process_by_vmthread(), the order is reversed.  
Can you explain why in the comments.


It looks like the thread can't continue while the handshake operation is 
in progress, so does the order matter?


This has the wrong @test name.  These could use an @comment line about 
what you expect also.  I don't know what's "Native" about it though, 
isn't it testing what happens when you use -XX:+ThreadLocalHandshakes?


This one too an @comment that it's testing the fallback VM operation 
would be good.

I don't need to see another webrev for the comment changes.

Lastly, as I said before, I think putting the safepoint polls in the 
interpreter at return and backward branches would be a good follow on 


On 10/11/17 9:37 AM, 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