Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8222518

Remove unnecessary caching of Parker object in java.lang.Thread

    XMLWordPrintable

Details

    • b36
    • 10
    • b19

    Backports

      Description

        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.

        Attachments

          Issue Links

            Activity

              People

                dholmes David Holmes
                dholmes David Holmes
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: