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

Dawid Weiss dawid.weiss at
Wed Aug 12 11:09:47 UTC 2015

FYI. Found it by bisecting hotspot changes and recompiling in
fastdebug. The problem is present consistently before this commit:

$ hg log -r 7381
changeset:   7381:03596ae35800
user:        aeriksso
date:        Thu May 21 16:49:11 2015 +0200
summary:     8060036: C2: CmpU nodes can end up with wrong type information

I cannot explain why -XX:-TieredCompilation helps here, perhaps it
collects different stats and the compilation graph is different (?).

In any case, the bug issue [1] has incorrect "Affect" field of "8u60";
should be at least "8x45", perhaps lower than that (and a related bug
[2] has it set correctly).



On Tue, Aug 11, 2015 at 11:27 PM, Dawid Weiss <dawid.weiss at> wrote:
> 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> 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

More information about the hotspot-compiler-dev mailing list