[
https://issues.apache.org/jira/browse/LUCENE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630811#action_12630811
]
Michael McCandless commented on LUCENE-1383:
--------------------------------------------
Hmm, the sometimes long-lasting bump in Used memory is odd.
When you close the old IndexSearcher & RAMDirectory do you forcefully
dereference them (set all variables that point to them to null) before then
reopening the new ones? (Seems like you must, since you saw the V shape before
LUCENE-1195, but I just want to verify). If you simply re-assign the variable
from old to new then two objects will exist at once until the opening of the
new one finishes.
I think the bump may just be GC taking its time collecting the objects, which
should be harmless. Maybe using a WeakReference to a long-lived object causes
GC to take longer to collect?
Is it possible to use the profiler to look for a reference to the old
RAMDirectory while the bump is "up"? That would be a smoking gun that we do
still have a reference, unless it's only via the WeakReference.
Or, could you try lowering the heap size in your JRE to something slightly less
than 2X one RAMDirectory (but not so low that the "other stuff" you have in the
JRE can't fit). This would force GC to work harder / more immediately in
reclaiming the unreachable objects.
> Work around ThreadLocal's "leak"
> --------------------------------
>
> Key: LUCENE-1383
> URL: https://issues.apache.org/jira/browse/LUCENE-1383
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 1.9, 2.0.0, 2.1, 2.2, 2.3, 2.3.1, 2.3.2
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 2.4
>
> Attachments: LUCENE-1383.patch, ScreenHunter_01 Sep. 13 08.40.jpg,
> ScreenHunter_02 Sep. 13 08.42.jpg, ScreenHunter_03 Sep. 13 08.43.jpg
>
>
> Java's ThreadLocal is dangerous to use because it is able to take a
> surprisingly very long time to release references to the values you
> store in it. Even when a ThreadLocal instance itself is GC'd, hard
> references to the values you had stored in it are easily kept for
> quite some time later.
> While this is not technically a "memory leak", because eventually
> (when the underlying Map that stores the values cleans up its "stale"
> references) the hard reference will be cleared, and GC can proceed,
> its end behavior is not different from a memory leak in that under the
> right situation you can easily tie up far more memory than you'd
> expect, and then hit unexpected OOM error despite allocating an
> extremely large heap to your JVM.
> Lucene users have hit this many times. Here's the most recent thread:
>
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200809.mbox/%3C6e3ae6310809091157j7a9fe46bxcc31f6e63305fcdc%40mail.gmail.com%3E
> And here's another:
>
> http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200807.mbox/%3CF5FC94B2-E5C7-40C0-8B73-E12245B91CEE%40mikemccandless.com%3E
> And then there's LUCENE-436 and LUCENE-529 at least.
> A google search for "ThreadLocal leak" yields many compelling hits.
> Sun does this for performance reasons, but I think it's a terrible
> trap and we should work around it with Lucene.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
