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

Threads spinning infinitely in WeakHashMap.get running test262parallel

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b56
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        When running test262parallel, it sometimes hangs indefinitely. Looks like this happens because sometimes threads try to read the protoHistory of the same PropertyMap at the same time it is being modified, and this unfortunately can lead to an infinite loop in WeakHashMap due to the way it is written (it is not threadsafe):

        at java.util.WeakHashMap.get(WeakHashMap.java:403)
        at jdk.nashorn.internal.runtime.PropertyMap.checkProtoHistory(PropertyMap.java:687)
        at jdk.nashorn.internal.runtime.PropertyMap.changeProto(PropertyMap.java:886)
        at jdk.nashorn.internal.runtime.ScriptObject.setProto(ScriptObject.java:1288)
        ...

        It seems that in a multithreaded environment, PropertyMap.history and .protoHistory would need to be threadsafe. They're both caches with weak keys and soft values (WeakHashMap<K, SoftReference<V>>) and WeakHashMap is unfortunately not threadsafe.

          Activity

          Hide
          attila Attila Szegedi added a comment -
          Currently the only solution is to synchronize on the WeakHashMap, which is a shame as it (a) imposes a performance penalty on single-threaded use of Nashorn and (b) most of the accesses are reads, not writes.

          Nashorn, being in the boot class path obviously can't use third-party libraries, but I know that there are reliably working cache implementations out there that allow you to build caches with weak keys and soft values and reads of already cached values that happen concurrently with each other and with any addition of new values to the cache. It'd be awesome if we had something like this in the base Java platform.
          Show
          attila Attila Szegedi added a comment - Currently the only solution is to synchronize on the WeakHashMap, which is a shame as it (a) imposes a performance penalty on single-threaded use of Nashorn and (b) most of the accesses are reads, not writes. Nashorn, being in the boot class path obviously can't use third-party libraries, but I know that there are reliably working cache implementations out there that allow you to build caches with weak keys and soft values and reads of already cached values that happen concurrently with each other and with any addition of new values to the cache. It'd be awesome if we had something like this in the base Java platform.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78f82d897305
          User: hannesw
          Date: 2015-03-13 17:41:08 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/78f82d897305 User: hannesw Date: 2015-03-13 17:41:08 +0000
          Hide
          hannesw Hannes Wallnoefer added a comment -
          Added noreg-hard as this bug only manifests itself rarely, in a test suite that takes several minutes to run.
          Show
          hannesw Hannes Wallnoefer added a comment - Added noreg-hard as this bug only manifests itself rarely, in a test suite that takes several minutes to run.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/78f82d897305
          User: lana
          Date: 2015-03-25 00:35:02 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/78f82d897305 User: lana Date: 2015-03-25 00:35:02 +0000

            People

            • Assignee:
              hannesw Hannes Wallnoefer
              Reporter:
              attila Attila Szegedi
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: