RFR(XL): 8185640: Thread-local handshakes

[Robbin Ehn]

Hi,

On 2017-10-20 18:24, Karen Kinnear wrote:
> Robbin, Erik, Mikael -
> 
> Delighted to see this! Looks good. I don’t need to see any updates - these are minor comments.
> Thank you for the performance testing
> 
> Couple of questions/comments:
> 1. platform support
> supports_thread_local_poll returns true for AMD64 or SPARC
> Your comment said Linux x64 and Sparc only.
> What about Mac and Windows?

Sorry it should be x64 and SPARC, OS is not important. (so yes mac and windows)

> 
> 2. safepointMechanism_inline.hpp - comment clarification
> line 42 - “Mutexes can be taken but none JavaThread”.
> Are you saying: “Non-JavaThreads do not support handshakes, but must stop for
> safepoints.”
> Not sure what the Mutex comment is about

Fixed:
"// If the poll is on a non-java thread, we can only check the global state."

This is possible from e.g. Monitor::TrySpin.

> 
> 3. globals.hpp
> The way I understand this - ThreadLocalHandshakes flag is not so much to enable
> use of ThreadLocalHandle operations, but to enable use of TLH for global safe point.
> If that is true, could you possibly at least clarify this in the comment if there is not
> a better name for the flag?

Fixed
"Use thread-local polls instead of global poll for safepoints."

We can also do better name of option, e.g. -XX:+(Use)ThreadLocalPoll ?
Let me know.

> 
> 4. thank you for looking into startup performance and interpreter return/backward branch checks.

We are committed to fix this before 18.3!

> 
> 5. handshake.cpp
> Could you possibly add a comment that thread_has_completed and/or pool_for_completed_thread
> means that the thread has either done the operation or the operation has been cancelled?
> I get that we are polling this to tell when it is safe to return to the synchronous requestor not to
> determine if the thread actually performed the operation. The comment would make that clearer.

Fixed

Incremental:
http://cr.openjdk.java.net/~rehn/8185640/v3/Assorted-Karen-5/webrev/

Again let me know if anyone needs another kind!

Thanks Karen!

/Robbin

> 
> thanks,
> Karen
> 
>> On Oct 11, 2017, at 9:37 AM, Robbin Ehn <robbin.ehn at oracle.com> 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
>