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

Dawid Weiss dawid.weiss at gmail.com
Thu Sep 3 06:29:35 UTC 2015


Thank you, Vladimir.

I need to spend one of those Poland's murky Autumn evenings studying all
those hs flags in globals.* :)

Dawid

On Thu, Sep 3, 2015 at 3:04 AM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> 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


More information about the hotspot-compiler-dev mailing list