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
