On 9/30/13 11:49 AM, Jochen Theodorou wrote: > Am 30.09.2013 17:10, schrieb Stefan Karlsson: > [...] >> First, my experiments were done without --indy so I might be seeing a >> different issue than you are. On the other hand, the experiments shows a >> real problem with our Metaspace and GC interaction, so I think that's >> worth investigating. >> >> The root cause of the problem I'm seeing is that SoftReferences are not >> cleared when the GC is triggered because of high metaspace memory >> pressure. I've created the bug: >> https://bugs.openjdk.java.net/browse/JDK-8025635 - SoftReferences are >> not cleared before metaspace OOME are thrown > > SoftReferences not cleared.. especially SoftReferences to Class and in > worst case a soft reference to an object that has a hard reference to > a class was always a critical point. We have some history with that. > And this I see as critical bug for us. So I am very happy if it gets > fixed before the final jdk8 ;) > > I did read your description and I think you should try with indy (also > see http://groovy.codehaus.org/InvokeDynamic+support). What I have > seen is not that metaspace increases indefinitely. Instead there is an > OOME, before free memory is exhausted. Granted, jdk8 did, as far as I > remember, allow about 4 times
The OOME was for an attempted allocation from the Java heap? In particular it was not an out-of-memory from an attempted metadata allocation? Jon > more classes to be created than jdk4u25, but it failed to clear the > number of loaded classes at one point... afaik that was somewhere at > 40k classes being loaded (and 38k of them dead). But of course it is > possible I missed that there can be no free memory claimed and maybe > the fix for JDK-8025635 is a fix for what I did see as well > > bye Jochen > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
