I was able to improve the behavior by setting the mapped ByteBuffer to null
in the close method of MMapIndexInput. This seems to be a strong enough
'suggestion' to the gc, as I can see the references go away with process
explorer, and the index files can be deleted, usually. Occasionally, a
reference to the '.tis' file remains.
Peter
On 6/5/06, Daniel Noll <[EMAIL PROTECTED]> wrote:
Peter Keegan wrote:
> There is no 'unmap' method, so my understanding is that the file mapping
is
> valid until the underlying buffer is garbage-collected. However, forcing
> the gc doesn't help.
You're half right.
The file mapping is indeed valid until the underlying buffer is garbage
collected, but you can't "force" the GC -- there is no API which does
that.
Note the wording in the Javadoc for System.gc():
"Calling the gc method **suggests** that the Java Virtual Machine
expend effort toward recycling unused objects in order to make the
memory they currently occupy available for quick reuse. When control
returns from the method call, the Java Virtual Machine has made a
best effort to reclaim space from all discarded objects."
> The file deletes don't fail on Linux, but I'm wondering if there is
still a
> memory leak?
Linux allows you to delete a file while someone has the file descriptor
open, but the file descriptor will remain valid (i.e. the delete doesn't
actually occur) until everyone releases the file descriptor.
I ran into similar issues as these when working on other things, and
eventually ended up switching to using a RandomAccessFile, as those can
be closed. Otherwise you're right -- the workaround is to routinely try
to delete the file.
Daniel
--
Daniel Noll
Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com.au/ Fax: +61 2 9212 6902
This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
