Transient miscompilation problem on 1.8 (invalid AIOOB/NPE thrown from the method body).

[Dawid Weiss]

We tried to narrow it down. The problem is tied to tiered compilation
somehow because turning it off makes the test pass with flying colors:

# 1.8.0_45-b14
PASSES -Xint
PASSES -Xmx4g -Xbatch -XX:CICompilerCount=1 -XX:-TieredCompilation
PASSES -Xmx4g                               -XX:-TieredCompilation
FAILS  -Xmx4g                               -XX:+TieredCompilation
FAILS  -Xmx4g -Xbatch -XX:CICompilerCount=2 -XX:+TieredCompilation

What's more interesting is that 1.9 and the most recent ea of 1.8
(u60) also pass, even with tiered compilation turned on:

# 1.9.0-ea-b71
PASSES -Xmx4g -Xbatch -XX:CICompilerCount=2 -XX:+TieredCompilation

# 1.8.0_60-ea-b25
PASSES [always, regardless of options]

I can't tell whether it's something masking the original problem or
whether the bug has been fixed in between. I looked at JIRA logs, but
can't find anything specific. If somebody knows what this could be,
I'd appreciate a pointer.

Dawid

On Tue, Aug 11, 2015 at 4:25 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> Hello,
>
> We have encountered a transient miscompilation problem (on 1.8u40). We
> get an AIOOB exception from a snippet of code which (provably) cannot
> throw it. The AIOOB is thrown without a stack trace. What's
> interesting is that when we set:
>
> -XX:-OmitStackTraceInFastThrow
>
> we get an NPE exception (which, again, is provably impossible at Java
> code level).
>
> The problem does not reproduce on my machine with i7 3770K (at least
> so far), but does reproduce consistently on i7 2600K (and our
> customer's machine; exact spec unknown).
>
> I will be looking into isolating this issue as it is in our
> proprietary code, but the pattern seems to be as follows:
>
> 1) new instance of A is created, with a new instance of B, which is a
> single-implementation of interface C.
>
> 2) there is a tight loop which calls A (and B) methods.
>
> There is no way for an AIOOB (or NPE) to be present in any of A or B,
> but the stack trace indicates A.
>
> I suspect an OSR miscompilation somewhere, but since I can't reproduce
> it locally it's a bit of a problem to experiment with JVM versions and
> internal flags.
>
> Any hints on what it can be related to (flags to try, etc.) would be
> appreciated.
>
> Dawid