You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Alain Stalder <as...@span.ch> on 2016/10/03 05:30:19 UTC

Re: Serious memory leak in groovy 2.4.7?

I just ran the tests of https://github.com/jexler/classgc with a current 
Groovy 2.4.8 SNAPSHOT (Oracle JDK 8, Mac).

As expected, the use case where Groovy classes are compiled and used 
from within Java/Groovy works now independently of whether the System 
Property groovy.use.classvalue is true or false.

(Also as expected, you still "only" get soft collection, i.e. you have 
to set a limit on Metaspace/PermGen and GC is only done once the limit 
is reached and can then block the VM noticeably for a moment. As 
discussed in the dev mailing list in May, there seems to be no way to 
get to automatic immediate GC once a Groovy class is no longer used 
without major changes in Groovy, i.e. not before a Groovy 3, because of 
the metadata attached to Groovy classes. Some partial workarounds had 
been discussed.)

(Also as expected, the use case where Groovy itself is loaded and 
unloaded multiple times ("Gradle use case") is still only working if 
groovy.use.classvalue is not explicitly set or explicitly set to false 
(soft collection here, too), but there is still an OutOfMemoryError if 
it is set to true. This is also known, and it would be nice if 
Orcacle/OpenJDK Java VMs in the future would be able to handle this case 
with ClassValue, but nothing that really can be done in Groovy itself to 
fix this.)

Looks good to me for a 2.4.8, a major improvement in the most common use 
cases (Groovy script evaluation, Groovy ConfigSlurper, etc.).

PS: And hey, if any of you guys want more control about Garbage 
Collecting Groovy classes, take a look at Grengine...

https://www.grengine.ch/manual.html#class-loading-and-garbage-collection