lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dawid Weiss (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()
Date Wed, 17 Feb 2016 08:01:18 GMT


Dawid Weiss commented on LUCENE-7032:

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:
-XX:-TieredCompilation -Xbatch -XX:CICompilerCount=1

Potential options for 3 are:
-XX:+MinInliningThreshold=250 (default)
-XX:+CompileThreshold=10000 (default)

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -------------------------------------------------
>                 Key: LUCENE-7032
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message