Upon further analysis, if I call
InvokerHelper.removeClass(clazz)
after I instantiate and use the instance, then things get unloaded correctly.
What is the right way to fix this? Is it to call this invoker method for all
classes I load or is the injected constructor code the problem?
regards
Saravanan
On 2020/09/08 00:59:34, Saravanan Palanichamy <[email protected]> wrote:
> Hello
>
> I am running into a memory leak issue with Groovy. I am not sure this has
> been fixed in newer releases. I am on 2.5.3
>
> * I compile my groovy files into a jar at compile time (I do not load
> dynamically)
> * I then use this code to load my jar
> val classloader =
> URLClassLoader(arrayOf(File("build/lib/My-process-1.0.jar").toURI().toURL()))
> val clazz = classloader.loadClass("com.MyProcess.MyClass")
> val method = clazz.getMethod("myProcess", String::class.java)
> val instance = Guice.createInjector(GroovyModule()).getInstance(clazz)
> method.invoke(instance, "")
> * If I run this in a loop 1000's of times and I profile it, I see that there
> are a lot of org.codehaus.groovy.runtime.metaclass.MetaMethodIndex$Entry
> entries in the heap
> * This steadily increases my memory foot print
> * I also noticed that if I dont create the class instance, but instead only
> load and unload the jar through a class loader, I dont see a memory leak
> * This leads me to think that this piece of code auto injected in the
> constructor has something to do with it?
> public MyClass() {
> MetaClass var2 = this.$getStaticMetaClass();
> this.metaClass = var2;
> }
>
> Any help is appreciated. I dont use dynamic invocation so I have no use for
> this metaclass. I compile all my scripts statically
>
> regards
> Saravanan
>
