OpenHFT / Zero-Allocation-Hashing

Zero-allocation hashing for Java
Apache License 2.0
793 stars 136 forks source link

Class loading deadlock when using LongTupleHashFunction & LongHashFunction #53

Closed blemale closed 2 years ago

blemale commented 3 years ago

zero-allocation-hashing version: 0.12 java version: 14 jvm: openjdk

We are experiencing class loading deadlock when using concurrently LongTupleHashFunction and LongHashFunction, here is the thread dump of the app when the deadlock occurs:

"default.work-dispatcher-39" #98 prio=5 os_prio=0 cpu=1399.65ms elapsed=747.54s tid=0x00007f54fc07b000 nid=0x7a in Object.wait()  [0x00007f540f4f2000]
   java.lang.Thread.State: RUNNABLE
        at net.openhft.hashing.LongHashFunction.murmur_3(LongHashFunction.java:223)
        - waiting on the Class initialization monitor for net.openhft.hashing.MurmurHash_3
        (...)
"default.work-dispatcher-48" #108 prio=5 os_prio=0 cpu=2235.06ms elapsed=747.42s tid=0x00007f5410038000 nid=0x84 in Object.wait()  [0x00007f540e4b5000]
   java.lang.Thread.State: RUNNABLE
        at net.openhft.hashing.LongHashFunction.murmur_3(LongHashFunction.java:223)
        - waiting on the Class initialization monitor for net.openhft.hashing.MurmurHash_3
        (...)
"default.work-dispatcher-50" #109 prio=5 os_prio=0 cpu=211.69ms elapsed=747.42s tid=0x00007f541003c000 nid=0x85 in Object.wait()  [0x00007f540e3b2000]
   java.lang.Thread.State: RUNNABLE
        at net.openhft.hashing.CompactLatin1CharSequenceAccess.<clinit>(CompactLatin1CharSequenceAccess.java:83)
        - waiting on the Class initialization monitor for net.openhft.hashing.UnsafeAccess
        at net.openhft.hashing.ModernCompactStringHash.<clinit>(ModernCompactStringHash.java:14)
        at net.openhft.hashing.Util.<clinit>(Util.java:41)
        at net.openhft.hashing.MurmurHash_3.<clinit>(MurmurHash_3.java:38)
        at net.openhft.hashing.LongHashFunction.murmur_3(LongHashFunction.java:223)
        (...)
"default.work-dispatcher-103" #195 prio=5 os_prio=0 cpu=378.90ms elapsed=727.08s tid=0x00007f54c8009800 nid=0xe1 in Object.wait()  [0x00007f539fdc6000]
   java.lang.Thread.State: RUNNABLE
        at net.openhft.hashing.UnsafeAccess.<clinit>(UnsafeAccess.java:30)
        - waiting on the Class initialization monitor for net.openhft.hashing.Util
        at net.openhft.hashing.LongTupleHashFunction.<clinit>(LongTupleHashFunction.java:948)
        (...)

NB: I have sanitised the stack traces to remove mention of our own classes.

gzm55 commented 3 years ago

the ut is tested against the JDK14. What is the java option and is the Class loaded by some special class loader?

gzm55 commented 2 years ago

@RobAustin Can we release version 0.15.1 fixing this issue?

kalaninja commented 2 years ago

Does anyone know if the version with this fix will be released?

RobAustin commented 2 years ago

see zero-allocation-hashing-0.16.pom just uploaded

hisener commented 2 years ago

0.16 doesn't seem to be available on Maven Central. 👀 https://search.maven.org/artifact/net.openhft/zero-allocation-hashing

alamar commented 2 years ago

Thank you for noticing this @hisener - we have re-deployed that version to Maven Central.

kalaninja commented 2 years ago

Thank you guys!