Questions about JDK-8136353 "ClassValue preventing class unloading"

Craig Andrews candrews at
Wed Jan 6 17:14:32 UTC 2016

I apologize for contacting this list - I'm sure this isn't the "right 
way" to contact the OpenJDK project, but I'm not clear what the "right 
way" is.

I'm hoping to raise 
"ClassValue preventing class unloading" as I believe it's a significant 
issue in ClassValue which is a blocker for its use in dynamic languages 
(which is primiarly why ClassValue was introduced). I think the P5 
priority set on the bug now is way too low, perhaps you could consider 
raising the priority?

The source code in the issue description is incorrect; it doesn't 
compile. Could you please attach the working test cases to the issue, so 
future testers and developers can reproduce the problem? Here are links 
to the 2 source code files:
(which of course should be directly attached to the openjdk issue 
tracker issue, and not hyperlinked to the Groovy tracker)

And to reproduce the issue, run:
$ javac && javac && mkdir -p t && jar cvf 
t/t.jar MyClassValue*.class && rm MyClassValue*.class && 
JAVA_OPTS=-Xmx4m java CVTest
and wait for the an error to occur, which is:
Exception in thread "main" java.lang.OutOfMemoryError: Compressed class 
     at java.lang.ClassLoader.defineClass1(Native Method)
     at java.lang.ClassLoader.defineClass(
     at Method)
     at java.lang.ClassLoader.loadClass(
     at java.lang.ClassLoader.loadClass(
     at CVTest.main(

The bug is reproducible on all JDK 8 and 9 builds (I tested up to JDK 9 
build 99).

Based on my understanding of the situation from my research in the 
Groovy bug that discovered the issue ( ) and some work 
another person did with the YourKit profiler ( ), I suspect 
that the fix for 
"ClassValue.ClassValueMap.type is unused" is relevant; I think the 
problem lies in the java.lang.Class.classValueMap implementation.

Thank you,
~Craig Andrews

More information about the mlvm-dev mailing list