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

Robbin Ehn robbin.ehn at oracle.com
Thu Apr 25 07:53:56 UTC 2019

Hi David,

Looks good.

Just a question:
It seems like we could just hold the ThreadsList over p->unpark() and not rely 
on TSM ?
Not sure in how many places we do rely on it, but it would be nice to remove TSM 
for parkers.
The exiting thread would set parker to NULL before removing itself from the 
threadslist and free it when it's off.

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