Questions about JDK-8136353 "ClassValue preventing class unloading"

[Peter Levart]

On 01/06/2016 09:34 PM, Peter Levart wrote:
> Hi Craig,
>
> I think that what you are asking for is impossible to achieve in 
> current Java.
>
> ClassValue API is basically a cache that maps a pair: (ClassValue<T>, 
> Class<?>) -> cached instance of type T
>
> You would like the cached instance of type T to not be reachable from 
> either ClassValue<T> instance or from Class<?> instance, but still be 
> non-reclaimable while either of 
correction: while either of ... or ... is -> while both of ... and ... are

> ClassValue<T> instance or Class<?> instance is reachable in some other 
> way that excludes being reachable from the cached instance of type T.
>
> For that to be achievable, Java would have to provide a feature called 
> "Ephemeron".
>
> Currently the cached instance of type T is reachable from Class<?> 
> instance and you are using Integer.TYPE in your example. Which means 
> that the cached instance of T is never going to be released if 
> ClassValue<T> instance is reachable from cached instance of T. In your 
> example, it is: (Dummy instance -> Dummy.class -> MyClassValue 
> instance). So you get this reachability chain: Integer.TYPE -> 
> ClassValueMap instance -> ClassValueMap.Entry[] -> ClassValueMap.Entry 
> -> Dummy instance -> Dummy.class -> MyClassValue instance.
> Integer.TYPE is a Class<?> instance representing int type which is 
> loaded by bootstrap class loader, which never goes away.
>
> ClassValue API could use a different strategy and reference the cached 
> instance of type T from ClassValue<T> instance instead, but then you 
> would have a problem with ClassValue instances reachable from other 
> class loaders than the cached instances of type T.
>
> Regards, Peter
>
> On 01/06/2016 06:14 PM, Craig Andrews wrote:
>> 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 https://bugs.openjdk.java.net/browse/JDK-8136353 
>> "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:
>> https://issues.apache.org/jira/secure/attachment/12765900/CVTest.java
>> https://issues.apache.org/jira/secure/attachment/12765901/MyClassValue.java 
>>
>> (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 MyClassValue.java && javac CVTest.java && 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 space
>>     at java.lang.ClassLoader.defineClass1(Native Method)
>>     at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
>>     at 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152)
>>     at java.net.URLClassLoader.defineClass(URLClassLoader.java:470)
>>     at java.net.URLClassLoader.access$100(URLClassLoader.java:76)
>>     at java.net.URLClassLoader$1.run(URLClassLoader.java:371)
>>     at java.net.URLClassLoader$1.run(URLClassLoader.java:365)
>>     at java.security.AccessController.doPrivileged(Native Method)
>>     at java.net.URLClassLoader.findClass(URLClassLoader.java:364)
>>     at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
>>     at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>>     at CVTest.main(CVTest.java:12)
>>
>> 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 ( 
>> https://issues.apache.org/jira/browse/GROOVY-6704 ) and some work 
>> another person did with the YourKit profiler ( 
>> https://www.yourkit.com/forum/viewtopic.php?f=3&t=12658 ), I suspect 
>> that the fix for https://bugs.openjdk.java.net/browse/JDK-8032606 
>> "ClassValue.ClassValueMap.type is unused" is relevant; I think the 
>> problem lies in the java.lang.Class.classValueMap implementation.
>>
>> Thank you,
>> ~Craig Andrews
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160106/e4d7f195/attachment-0001.html>