I was using jpython-1.0.3 on Sun JDK 1.2.
The last paragraph of this message seems to
confirm the presence of the problem:
The problem can be reproduced with the following
$ cat testeval.py
$ cat testexecfile.py
$ cat test.py
If you leave these programs running for a while and look at them
in top, you can see the leak.
From: Samuele Pedroni <pedroni@...>
To: arun@... <arun@...>;
Date: Monday, November 06, 2000 5:07 AM
Subject: execfile/eval classes not GC'ed
>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
>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 -------------