Under which jvms does this happen?
Can you produce a minimal example?
As far as I know, if things are setup properly java machines
collect classloaders and classes too.
So it is possible that we can solve it.
Your proposal sounds like a "desparate" workaround, have you analyzed the
situation/code in order to exclude other possibilities? so could you precisely
explain why classes are not GC'ed or that's a jvm bug needing a workaround.
At the moment part of the loading in jython is under reworking.
I will try to track the problem, a failing example would be a nice
start point. It is possible that references are kept around that
------------- Begin Included Message -------------
Bug #121738, was updated on 2000-Nov-05 23:32
Here is a current snapshot of the bug.
Bug Group: None
Summary: Memory leaks due to classes not being GC'ed
Going by previous exchanges on the mailing lists,
this seems to be a known problem.
When a execfile() or eval() is repeatedly
executed in a long running java process, a
new class gets created on every invocation.
This class does not get garbage collected
as long as the classloader which loaded it
This leads to a bloat of the java process
size (not in the heap, but in the code blocks).
Eval is kind of dispensable, but execfile is
not. One easy fix would be to cache the generated
class and reuse it the next time execfile is
I can readily provide those patches. Is this
acceptable or is a different solution already
in the works ?
------------- End Included Message -------------