groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Boon <kyle.f.b...@gmail.com>
Subject Memory leaks, GroovyClassLoader, and the MetaClassRegistry
Date Mon, 01 Jun 2015 20:13:06 GMT
We have a memory leak that I'm fairly confident that can be traced back to
this issue:

http://stackoverflow.com/questions/14343393/using-groovyclassloader-from-java-classes-not-gcd

We have a lot of REST services that result in code being compiled and
executed during the HTTP request.  I'm exploring a few different options to
try to fix the memory leak by removing the class from the MetaClassRegistry
which (should) allow the class to be garbage collected during the next full
GC.  At the end of the request, while there is still an instance of the
compiled Script class, I could remove the class from the MetaClassRegistry
explicitly. Or, I could create a background job that would find all
compiled Script classes and remove them from the MetaClassRegistry in bulk.

Complicating this slightly is that in order to reduce the number of times
we actually need to compile code, we put the compiled class into a Guava
cache. Then we can avoid the compilation step the majority of the time. My
question is, what happens if the class is removed from the
MetaClassRegistry and then another instance of that class is created later?
Would it be worth it to try to recreate the meta class for the script class
if it was missing? Or is this just a fool's errand?

Thanks,

Kyle

Mime
View raw message