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 2016/02/17 09:01:18 UTC
[jira] [Comment Edited] (LUCENE-7032) jdk-9-ea+105 breaks
MinimizeOperations.minimize()
[ https://issues.apache.org/jira/browse/LUCENE-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150074#comment-15150074 ]
Dawid Weiss edited comment on LUCENE-7032 at 2/17/16 8:01 AM:
--------------------------------------------------------------
I'd try to make it more consistent by:
1) trying to make the compiler deterministic (I'm guessing C2),
2) trying to make the compiler run sequentially,
3) maybe we can lower some compilation threshold a bit or deoptimize a lot to throw some noise at the compiler... if it speeds up the repro, otherwise it doesn't make sense as it'd contribute lots of irrelevant compilation logs.
Options for 1 and 2 are:
{code}
-XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1
{code}
Potential options for 3 are:
{code}
-XX:+DeoptimizeALot
-XX:+MinInliningThreshold=250 (default)
-XX:+CompileThreshold=10000 (default)
{code}
was (Author: dweiss):
I'd try to make it more consistent by:
1) trying to make the compiler deterministic (I'm guessing C2),
2) trying to make the compiler run sequentially,
3) maybe we can lower some compilation threshold a bit or deoptimize a throw some noise at the compiler... if it speeds up the repro, otherwise it doesn't make sense as it'd contribute lots of irrelevant compilation logs.
Options for 1 and 2 are:
{code}
-XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1
{code}
Potential options for 3 are:
{code}
-XX:+DeoptimizeALot
-XX:+MinInliningThreshold=250 (default)
-XX:+CompileThreshold=10000 (default)
{code}
> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -------------------------------------------------
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been sporatically failing in non-reproducible ways. All of them invoke hopcroft minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, but I've at least got it where I can make it fail in a few minutes with beasting, so we can try simple things like turning on/off jvm flags to try to narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately it takes many thousands of iterations until we understand more about it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org