Am 20.09.2013 10:25, schrieb Benjamin Sieffert: > Hi Jochen, > > thanks for responding. I'm not really sure whether nashorn sets new > callsites every time. In profiling I only see it initally (when script > engines have just been initialized) and when the bad condition arises.
it is really only an assumption, but this really looks typical to soft referenced classes to me. It is done at the beginning and once memory requirements get strict, the references are released, but since they are needed right away again, they have to be recreated. > As for it being due to low memory, I'm not sure. Sometimes heap will > have been up to 450mb, been collected, risen from 250 to 350mb and then > the bad condition arises. So it's not 100% tied to low memory, but still > running a gc will always make the condition disappear. How about permgen? It is easy to proof the theory.. increase heap and permgen memory and you should observe the problem at a later point. If you have some luck, you may not experience it anymore at all. But if there are continuously new classes created to answer the requests (and I don't mean classes created by the jdk internals), the behaviour should appear again bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
