jdk8 metaspace problem with indy

[Stefan Karlsson]

On 2013-09-30 16:48, Coleen Phillimore wrote:
>
> Hi,  Stefan has found the cause of the problem you have described this 
> thread, but we're discussing internally how to fix it.  I'll let him 
> explain.

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

StefanK

>
> Thanks,
> Coleen
>
> On 09/26/2013 10:20 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> probably not such a good time to ask, since many of those, that could
>> answer this might be on JavaOne... but still
>>
>> On the user list we got an interesting program that makes quite some
>> problems to the jvm as it seems. The groovy program looks like this:
>>
>>>      println "Started"
>>>      for(int i = 0; i < 100; i++) {
>>>          print "."
>>>          for (int j=0;j<100000;j++) {
>>>              Container c = new Container()
>>>              c.run()
>>>          }
>>>      }
>>>      println "\ndone"
>>>
>>> public class Container implements Runnable {
>>>    public Container() {}
>>>    public void run() {
>>>      GroovyShell gs = new GroovyShell()
>>>      Script script = gs.parse("")
>>>      script.run()
>>>    }
>>> }
>> What happens is that gs.parse will create a new script and a new class
>> every time. Now using our custom call site code this works fine. Using
>> the indy port, it fails with a permgen error on any jdk7 before u40. On
>> u40 this works fine again. In jdk8 this fails sometimes with a metaspace
>> error, while in u40 it seems to work quite reliable.
>>
>> The problem must be more than just creating many classes, because our
>> custom callsite caching creates just as many classes for the scripts as
>> the indy version does. What does not happen so much there though is code
>> generated by reflection and of course non from indy. So I especially
>> suspect the code cache here to be responsible for the problem, but I
>> have no real basis for this. I lack the means to diagnose the problem
>> further
>>
>> Is there a way to make this work on older jdk7 vms? And is there a way
>> for me to make this work on jdk8? Do others here have similar 
>> experiences?
>>
>> bye Jochen
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130930/0f67df70/attachment.html