lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <ysee...@gmail.com>
Subject Re: JVM Crash in Lucene
Date Sun, 11 Dec 2005 16:01:27 GMT
You also might try -Xbatch or -Xcomp to see if that fixes it (or
reproduces it faster).

Here's a great list of JVM options:
http://blogs.sun.com/roller/resources/watt/jvm-options-list.html

-Yonik

On 12/11/05, Yonik Seeley <yseeley@gmail.com> wrote:
> Sounds like it's a hotspot bug.
> AFAIK, hotspot doesn't just compile a method once... it can do
> optimization over time.
>
> To work around it, have you tried pre previous version: 1.5_05?
> It's possible it's a fairly new bug.  We've been running with that
> version and Lucene 1.4.3 without problems (on Opteron, RHEL4).
>
> You could also try the latest Lucene 1.9 to see if that changes enough
> to avoid the bug.
>
> -Yonik
>
> On 12/11/05, Dan Gould <dlg@cs.brown.edu> wrote:
> > First, thank you Chris, Yonik, and Dan for your ideas as to what might be
> > causing this problem.
> >
> > I tried moving things around so that the IndexReader is still open when it
> > calls TermFreqVector.getTerms()/TermFreqVector.getTermFrequencies().  It
> > didn't seem to make any difference.
> >
> > I also tried running Java with the flags:
> > -Xmx2048m -XX:MaxPermSize=200m
> > (the box has 4GB of RAM) and it still crashes.  It's hard to tell, but the
> > program does seem to run for a lot longer (maybe 10 hours), but that could
> > just be randomness in my tests.
> >
> > The JVM always seems to crash with
> >
> >   Current CompileTask:
> >   opto:1836
> >   org.apache.lucene.index.IndexReader$1.doBody()Ljava/lang/Object;
> >   (99 bytes)
> >
> > which in the Lucene source is:
> >
> >    private static IndexReader open(final Directory directory, final boolean
> > closeDirectory) throws IOException {
> >      synchronized (directory) {                   // in- & inter-process
> > sync
> >        return (IndexReader)new Lock.With(
> >            directory.makeLock(IndexWriter.COMMIT_LOCK_NAME),
> >            IndexWriter.COMMIT_LOCK_TIMEOUT) {
> >            public Object doBody() throws IOException {
> >              SegmentInfos infos = new SegmentInfos();
> >              infos.read(directory);
> >              if (infos.size() == 1) {             // index is optimized
> >                return SegmentReader.get(infos, infos.info(0),
> > closeDirectory);
> >              }
> >              IndexReader[] readers = new IndexReader[infos.size()];
> >              for (int i = 0; i < infos.size(); i++)
> >                readers[i] = SegmentReader.get(infos.info(i));
> >              return new MultiReader(directory, infos, closeDirectory,
> > readers);
> >
> >            }
> >          }.run();
> >      }
> >    }
> >
> > that's definitely a non-trivial bit of code, but I can't imagine that
> > there's a problem that I'm seeing that no one else else.  Moreover, that
> > code gets run hundreds or even thousands of times before it crashes, so I
> > don't image it's being HotSpot-compiled for the first time.
> >
> > I'm running the 1.4.3 release and the 1.5.0_06-b05 JVM on Centos Linux on
> > an Opteron.
> >
> > Any further guesses?
> >
> > Thank you all very much,
> > Dan
>

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


Mime
View raw message