RFR(XL): 8185640: Thread-local handshakes

[Robbin Ehn]

Thanks Nils for looking at that!

/Robbin

On 2017-10-17 16:37, Nils Eliasson wrote:
> Hi Robbin,
> 
> I have reviewed the compiler parts of the patch - c1, c2, jvmci and cpu*.
> 
> Look great!
> 
> Regards,
> 
> Nils
> 
> 
> 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
>