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 <chava...@gmail.com> 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 >