RFR(XL): 8185640: Thread-local handshakes
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Thu Oct 19 13:56:17 UTC 2017
Thank you this is better.
In this test, what happens if it fails?
Everything looks better with this change.
On 10/19/17 8:40 AM, Robbin Ehn wrote:
> Here is the third incremental change:
> Goes on top of Atomic-Update-Rebase-3.
> Let me know if anyone want to see some other kind of webrevs.
> Thanks, Robbin
> On 2017-10-18 11:15, Robbin Ehn wrote:
>> Hi all,
>> Update after re-base with new atomic implementation:
>> 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:
>>> Divided into 3-parts,
>>> SafepointMechanism abstraction:
>>> Consolidating polling page allocation:
>>> 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
>>> -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:
>>> which puts all JavaThreads in an array instead of a linked list.
>>> Thanks, Robbin
More information about the hotspot-dev