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

[Andreas Eriksson]

Hi,

On 2015-09-03 08:29, Dawid Weiss wrote:
> 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.
For your information:
The bug was introduced in 8u20 by 8042786 
<https://bugs.openjdk.java.net/browse/JDK-8042786>.
I updated the affects field again, and added a related-to 8042786.

Regards,
Andreas

>>
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150903/2f3ceb04/attachment.html>