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

[Vladimir Kozlov]

Thank you for reporting this, Dawid.

I added 8u40 affected version. And I added you finding as comment into 
the bug report 8060036.

One additional thing you can try next time is isolate which compiler, C1 
and C2, causing problem in Tiered VM. To run only C1: 
-XX:+TieredCompilation -XX:TieredStopAtLevel=1

Thanks,
Vladimir

On 8/12/15 4:09 AM, Dawid Weiss wrote:
> 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).
>
> Dawid
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8060036
> [2] https://bugs.openjdk.java.net/browse/JDK-8080156
>
> On Tue, Aug 11, 2015 at 11:27 PM, Dawid Weiss <dawid.weiss at gmail.com> 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 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