RFR(S): 8222518: Remove unnecessary caching of Parker object in java.lang.Thread

Robbin Ehn robbin.ehn at oracle.com
Fri Apr 26 08:14:30 UTC 2019

> I'll file a RFE for that.

Great, thanks!


> Thanks,
> David
>> Thanks, Robbin
>> On 4/24/19 9:12 AM, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
>>> webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
>>> The original implementation of Unsafe.unpark simply extracted the JavaThread 
>>> reference from the java.lang.Thread oop and if non-null extracted the Parker 
>>> instance from it and invoked unpark. This was racy however as the native 
>>> JavaThread could terminate at any time and deallocate the Parker.
>>> That logic was fixed by JDK-6271298 which used of combination of 
>>> type-stable-memory "event" objects for the Parker, along with use of the 
>>> Threads_lock to obtain the initial reference to the Parker (from a JavaThread 
>>> guaranteed to be alive), together with caching the native Parker pointer in a 
>>> field of java.lang.Thread. Even though the native thread may have terminated 
>>> the Parker was still valid (even if associated with a different thread) and 
>>> the unpark at worst was a spurious wakeup for that other thread.
>>> When JDK-8167108 introduced Thread Safe-Memory-Reclaimation (SMR) the logic 
>>> was updated to always use the safe mechanism - we grab a ThreadsListHandle 
>>> then check the cached field, else lookup the native thread to see if it is 
>>> alive and locate the Parker instance that way.
>>> With SMR the caching of the Parker pointer no longer serves any purpose - we 
>>> no longer have a lock-free use-the-cache path versus a lock-using 
>>> populate-the-cache path. With SMR we've already"paid" for the ability to 
>>> ensure the native thread can't terminate regardless of whether we lookup the 
>>> field from the java.lang.Thread or the JavaThread. So we can simplify the 
>>> code and save a little footprint by removing the cache from java.lang.Thread:
>>>      /*
>>>       * JVM-private state that persists after native thread termination.
>>>       */
>>>      private long nativeParkEventPointer;
>>> and the supporting code from unsafe.cpp and javaClass.*pp in the JVM.
>>> I considered restoring the fast-path use of the cache without recourse to 
>>> Thread-SMR but performance measurements failed to show any benefit in doing. 
>>> See bug report for details.
>>> Thanks,
>>> David

More information about the core-libs-dev mailing list