This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: leak in gnu.bytecode.ZipLoader


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

> but even if there was nothing preventing the ZipLoader from being GC'd,
> this error could potentially occur many times before finalization
> cleans it up, so it's not clear that it's a good idea to rely on the
> GC to take care of this. in the extreme, one might not be aware this
> is happening until the process hits its limit of open file descriptors.

We either (1) keep the ZipFile open as long as it is (may be) needed,
or we (2) read everything in when the ZipLoader is constructed, or
(4) the ZipLoader re-opens the ZipFile on each loadClass, or we
(3) rely on the caller to tell the ZipLoader which to do.  There are
performance implications each way, so I suggest (3), defaulting to (1).

A more complex solution is to have a ZipLoaderManager which keeps track
of the open ZipFiles and closes the least recently used when one is
(re-)opened, allowing some small number (one or two?) to be open at
once.  This is probably overkill.  (An implementation that does not
rely on Java2 weak references is to implement the state of a ZipLoader
as containing just an integer index into a table in the ZipLoaderManager.
All ZipLoader operations, including finalization, are indirected to
the ZipLoaderManager.)

>  > 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.
> 
> 
> This seems like a fine solution (modulo my disagreement about relying
> on finalizations to clean up, but I can live with that).

could I ask you to implement this?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]