RFR(XL): 8185640: Thread-local handshakes

[Doerr, Martin]

Hi Robbin,

my first impression is very good. Thanks for providing the webrev.

I only don't like that "poll_page_val | poll_bit()" is used in shared code. I'd prefer to use either one or the other mechanism.
Would it be ok to move the decision between what to use to platform code?
(Some platforms could still use both if this is beneficial.)

E.g. on PPC64, we'd like to use conditional trap instructions with special bit patterns if UseSIGTRAP is on. Would be excellent if we could implement set functions for _poll_armed_value and _poll_disarmed_value in platform code. poll_bit() also fits better into platform code in my opinion.

Best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Robbin Ehn
Sent: Mittwoch, 11. Oktober 2017 15:38
To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: RFR(XL): 8185640: Thread-local handshakes

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