Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Fri, 18 Aug 2006 12:02:25 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: java-dev@lucene.apache.org
Subject: Re: Custom sorting - memory leaks
In-Reply-To: <3e8ef54f0608180201s185e6832w6ad5c50a88428dea@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0608181151300.31103@hal.rescomp.berkeley.edu>
References: <3e8ef54f0608180201s185e6832w6ad5c50a88428dea@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: You can reproduce OutOfMemory easily. I've attach test files - this is
: altered DistanceSortingTest example from LIA book. Also you can
: profile it and see caching of distances arrays.

An OutOfMemory error is differnet from a memory leak.  Sorting with a
custom Comparator does in fact use a lot of memory -- and if your Heap
size is not big enough you may get an OutOfMemory -- but that doesn't mean
you have a memory leak.  A Memory leak is a problem where memory is
allocated for objects, but not freed up once those objects are no longer
of use -- just becuase you aren't using those objects, doesn't mean they
aren't "of use" and it doesn't mean they won't be freed up once some
futher action is taken (ie: closing of an IndexReader)

Are you sure you've found an actual memory leak? ... ie: do you have a
demonstratable test case that shows heap usage growing without bound over
time?   If so then seeing *that* code would be helpful to figure out if
there is in fact a memory leak in Lucene, or if (perhaps) there is a
mistaken assumption in your code (ie; not closing an IndexReader)


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org