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.
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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
