Re: leak in gnu.bytecode.ZipLoader

[Per Bothner <per at bothner dot com>]

Thomas Kirk <tk@research.att.com> writes:

> so, the problem here is that ZipLoader holds the archive open until it
> has read all of the classes from the archive, but in some(?) cases not
> all of the classes are actually read, so the archive remains open
> indefinitely.

But it should get closed when the ZipLoader is finalized.  Are you
keeping lots of ZipLoader instances around?  I designed ZipLoader for
the case where you normally only keep a few instances around.  Still,
I can see that if you call (load "...zip") many times, and each time
one or two clases don't get loaded, there could be a problem.

> two possible workarounds: 
> (1) let loadCompiled (in kawa/standard/load.java) explicitly close the
> archive. Not clear that this is correct, as I haven't discerned the
> cases where the classloader will need subsequent access to the archive.

It could happen if the ZipLoader contains a class which defines a
procedure that doesn't get called for a while.

> (2) let ZipLoader read/define all of the classes from the archive on
> first access, store them in loadedClasses, and close the archive.

My ideal solution:

* Keep the default as is - i.e. the archive isn't closed until either
all classes have been loaded, or the ZipLoader is finalized.
* Add a 'loadAll' method, which loads all classes that haven't been loaded
yet, but without calling resolveClass.
* Add a 'closeZip' method which closes the underlying ZipFile.  Also add
logic to re-open the ZipFile if needed by a subsequent loadClass.
* Have loadCompiled call the 'loadAll' method.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/