G1GC/ JIT compilation bug hunt.

[Dawid Weiss]

> It is with high probability Compiler problem.

I believe so. I've re-run the tests with 1.8b102 and the problem is
still there, although it's more difficult to show -- I ran a 100 full
builds yesterday, five of them tripped on assertions that should be
unreachable.

> G1 has larger write-barrier code then other GCs. It can affect inlining
> decisions. You can try to change -XX:InlineSmallCode=1000 value. It controls
> inlining of methods which were already compiled.
>
> You can also try -Xbatch -XX:CICompilerCount=1 to get serial compilations.

Thanks for these tips, Vladimir -- very helpful. I hope you don't mind
me asking one more question - we had a discussion with another Lucene
developer yesterday -- is -Xbatch deterministic in the sense that if
you run a single thread/ deterministic piece of code it will always
trigger compiles at the same time? What happens if there are two
uncoordinated threads that hit a set of the same methods (and thus
when the compiler kicks in the statistics will probably be different
for each independent run)?

This question originated from a broader discussion where we were
wondering how you, the compiler-guru guys approach the debugging in
case something like this pops up -- a bug that is very hard to
reproduce, that manifests itself rarely and for which pretty much any
change at the Java level changes the compilation and thus generates
completely different code. This seems to be a tough nut to crack.

Dawid