Trove and G1GC compatibility

[prabhu damodharan]

usage of G1GC strategy for garbage collection results in JVM crash with the following the error

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000002aa8329, pid=5348, tid=4788
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# J  gnu.trove.impl.hash.TObjectHash.insertKey(Ljava/lang/Object;)I
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

[Rob Eden]

That's going to be a problem with the JVM, not Trove. There should be no pure Java code that can be written that could crash the JVM and Trove is pure Java (with no "sun.misc.Unsafe" silliness or anything like that).

[Scott Banachowski]

I've encountered the same crash when switching from Java 6 to Java 7. It's also been reported/discussed by others on stack overflow: http://stackoverflow.com/questions/11293384/jvm-crash-with-g1-gc-and-trove-library.

From what I've read, if you get a SEGV from compiled java code, it is likely due to a compiler bug that has resulted in incorrect code generation. I'm wondering if the jar we retrieved from the online artifact has an incompatibility with Java 7. Perhaps compiling the jar ourselves with a java 7 compiler might help.

[Rob Eden]

@sbanacho - It still shouldn't really be able to cause the problem. The fault for the crash would still lay with the GC. That being said... dunno, it may help. How often do you see the problem? Would you be able to call it "fixed" if you didn't see a crash after some amount of time?

There's really nothing interesting happening with the insertKey method. No idea why the GC would be unhappy with it.

[Scott Banachowski]

Yeah, I agree the code in trove looks innocuous, and shouldn't crash a jvm.

Somebody posted this https://jira.terracotta.org/jira/browse/CDV-1651, which has some code to reproduce the problem in isolation, so we may experiment with that, and see if changing compilers or switching GC, etc. helps.

[Kimoon Kim]

It appears that this is indeed a JDK bug, https://bugs.openjdk.java.net/browse/JDK-8023472, fixed by Java 7 update 65+.

[Gesly George]

@kimoon @robeden Sorry about commenting on a closed issue, but I'm seeing a somewhat similar issue where the JVM crashes due to some bad optimization by the C2 Compiler. This is using the latest JDK 8u92 and trove 3.0.3. Everytime that particular piece of code runs, the JVM crashes; it is on the insertKey method. Trying to find out if others have seen similar issues?