You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Dawid Weiss (JIRA)" <ji...@apache.org> on 2013/08/15 11:22:49 UTC
[jira] [Comment Edited] (LUCENE-5168) ByteSliceReader assert trips
with 32-bit oracle 1.7.0_25 + G1GC
[ https://issues.apache.org/jira/browse/LUCENE-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740829#comment-13740829 ]
Dawid Weiss edited comment on LUCENE-5168 at 8/15/13 9:21 AM:
--------------------------------------------------------------
Yeah, I agree. It isn't a trivial single-method issue though. nextSlice is indeed the problem, but it's inlined heavily in a number of places (and probably optimized wherever it's inlined). I've experimented with the following:
- "-XX:-Inline" - no errors
- excluding the "parent" method from compilation (which seems to be the root of the problem): org/apache/lucene/index/FreqProxTermsWriterPerField,flush - no errors
- "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors
- enforcing value flush in ByteSliceReader.nextSlice by modifying:
{code}
buffer = pool.buffers[bufferUpto];
upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
{code}
to
{code}
buffer = pool.buffers[bufferUpto];
foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
{code}
where foo is defined as a static field with no other accesses:
{code}
static int foo;
{code}
This also results in no errors.
I also dumped the generated assembly for the flush() method (you have to dump the parent method because of the inlines) but it's huge and, sigh, it's sometimes different even for two runs with identical options. I'm guessing parallel compilation tasks hit different stats and hence the difference.
was (Author: dweiss):
Yeah, I agree. It isn't a trivial single-method issue though. nextSlice is indeed the problem, but it's inlined heavily in a number of places (and probably optimized wherever it's inlined). I've experimented with the following:
- "-XX:-Inline" - no errors
- excluding the "parent" method from compilation (which seems to be the root of the problem): org/apache/lucene/index/FreqProxTermsWriterPerField,flush - no errors
- "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors
- enforcing value flush in ByteSliceReader.nextSlice by modifying:
{code}
buffer = pool.buffers[bufferUpto];
upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
{code}
to
{code}
buffer = pool.buffers[bufferUpto];
foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
{code}
where foo is defined as a static field with no other accesses:
{code}
static int foo;
{code}
I also dumped the generated assembly for the flush() method (you have to dump the parent method because of the inlines) but it's huge and, sigh, it's sometimes different even for two runs with identical options. I'm guessing parallel compilation tasks hit different stats and hence the difference.
> ByteSliceReader assert trips with 32-bit oracle 1.7.0_25 + G1GC
> ---------------------------------------------------------------
>
> Key: LUCENE-5168
> URL: https://issues.apache.org/jira/browse/LUCENE-5168
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: java8-windows-4x-3075-console.txt
>
>
> This assertion trips (sometimes from different tests), if you run the highlighting tests on branch_4x with r1512807.
> It reproduces about half the time, always only with 32bit + G1GC (other combinations do not seem to trip it, i didnt try looping or anything really though).
> {noformat}
> rmuir@beast:~/workspace/branch_4x$ svn up -r 1512807
> rmuir@beast:~/workspace/branch_4x$ ant clean
> rmuir@beast:~/workspace/branch_4x$ rm -rf .caches #this is important,
> otherwise master seed does not work!
> rmuir@beast:~/workspace/branch_4x/lucene/highlighter$ ant test
> -Dtests.jvms=2 -Dtests.seed=EBBFA6F4E80A7365 -Dargs="-server
> -XX:+UseG1GC"
> {noformat}
> Originally showed up like this:
> {noformat}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6874/
> Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC
> 1 tests failed.
> REGRESSION: org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testUserFailedToIndexOffsets
> Error Message:
> Stack Trace:
> java.lang.AssertionError
> at __randomizedtesting.SeedInfo.seed([EBBFA6F4E80A7365:1FBF811885F2D611]:0)
> at org.apache.lucene.index.ByteSliceReader.readByte(ByteSliceReader.java:73)
> at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108)
> at org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:453)
> at org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
> at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
> at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
> at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
> at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:501)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org