Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: domain of peterlkeegan@gmail.com
 designates 64.233.166.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=rVNj6Zxxj2L+g0xA7GMe8nEOOL3YMlq5Xd8ACQf6YNaMc1dkKXQPkHR+DfbZoJM/UYSmCGb30WpzNmKVtOmbN3QR11NMwdC8dCKQIBGYvbKh6fR2LX8SVeNa2YWn5QwcZ5JU/J2nn4nqkIQ1QvO12q6JtlPwnhO2e25wqcpgHog=
Message-ID: <e994873a0606070804k3e36029bxb7443cbf450a4555@mail.gmail.com>
Date: Wed, 7 Jun 2006 11:04:16 -0400
From: "Peter Keegan" <peterlkeegan@gmail.com>
To: java-user@lucene.apache.org
Subject: Re: MMapDirectory vs RAMDirectory
In-Reply-To: <4484C6DC.9020009@nuix.com.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4436_26692321.1149692656696"
References: <429c032d0605280109i7f0c8392x6d0017a5f6b70aac@mail.gmail.com>
	 <20060528082805.97131.qmail@web25915.mail.ukl.yahoo.com>
	 <e994873a0606050654u5a65c8cdq84aea688e741ca2@mail.gmail.com>
	 <4484C6DC.9020009@nuix.com.au>

------=_Part_4436_26692321.1149692656696
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <daniel@nuix.com.au> 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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

------=_Part_4436_26692321.1149692656696--