<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2013-09-30 16:48, Coleen Phillimore
wrote:<br>
</div>
<blockquote cite="mid:52498F22.6020706@oracle.com" type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
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:<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8025635">https://bugs.openjdk.java.net/browse/JDK-8025635</a>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
- SoftReferences are not cleared before metaspace OOME are thrown<br>
<br>
StefanK<br>
<br>
<blockquote cite="mid:52498F22.6020706@oracle.com" type="cite">
<br>
Thanks,
<br>
Coleen
<br>
<br>
On 09/26/2013 10:20 AM, Jochen Theodorou wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
probably not such a good time to ask, since many of those, that
could
<br>
answer this might be on JavaOne... but still
<br>
<br>
On the user list we got an interesting program that makes quite
some
<br>
problems to the jvm as it seems. The groovy program looks like
this:
<br>
<br>
<blockquote type="cite"> println "Started"
<br>
for(int i = 0; i < 100; i++) {
<br>
print "."
<br>
for (int j=0;j<100000;j++) {
<br>
Container c = new Container()
<br>
c.run()
<br>
}
<br>
}
<br>
println "\ndone"
<br>
<br>
public class Container implements Runnable {
<br>
public Container() {}
<br>
public void run() {
<br>
GroovyShell gs = new GroovyShell()
<br>
Script script = gs.parse("")
<br>
script.run()
<br>
}
<br>
}
<br>
</blockquote>
What happens is that gs.parse will create a new script and a new
class
<br>
every time. Now using our custom call site code this works fine.
Using
<br>
the indy port, it fails with a permgen error on any jdk7 before
u40. On
<br>
u40 this works fine again. In jdk8 this fails sometimes with a
metaspace
<br>
error, while in u40 it seems to work quite reliable.
<br>
<br>
The problem must be more than just creating many classes,
because our
<br>
custom callsite caching creates just as many classes for the
scripts as
<br>
the indy version does. What does not happen so much there though
is code
<br>
generated by reflection and of course non from indy. So I
especially
<br>
suspect the code cache here to be responsible for the problem,
but I
<br>
have no real basis for this. I lack the means to diagnose the
problem
<br>
further
<br>
<br>
Is there a way to make this work on older jdk7 vms? And is there
a way
<br>
for me to make this work on jdk8? Do others here have similar
experiences?
<br>
<br>
bye Jochen
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>