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