Array not zeroed on creation

[Vitaly Davidovich]

Thanks Kris.  What I meant was whether the control flow graph became a bit
more complex which caused the optimizer to miss the obvious use before
fill() is called.  I certainly understand that the code gen will still emit
a 0 check (with an uncommon trap presumably).

Since you're already playing with this, can you try doing something
"obvious" and unpredicated with the array between alloc and fill(), and see
if it still repros?

Sent from my phone
On Sep 7, 2012 11:42 AM, "Krystal Mo" <krystal.mo at oracle.com> wrote:

>  The "if"s are there all right, no worries. It's just the check for uses
> between the allocation and the fill that's missing (incorrectly removed by
> the OptimizeFill feature).
>
>   0x00007f5b4905f16d: mov    0x18(%rax),%r10d
>   0x00007f5b4905f171: test   %r10d,%r10d
>   0x00007f5b4905f174: jne    0x00007f5b4905f2fd  ;*ifeq
>                                                 ; - Test7196857::main at 42(line 10)
>
> The zero check loop in the test case is unrolled; the quoted code above is
> one of the unrolled checks.
>
> - Kris
>
> On 09/07/2012 11:30 PM, Vitaly Davidovich wrote:
>
> I wonder if the "if" is messing this up as well; interpreter profile will
> indicate that the branch is never taken since interpreter will always zero
> the array.  Otherwise, this bug seems a bit more "obvious" in the sense
> that testing would've caught it, I'd think, if it always eliminated zeroing
> (I.e. use after new'ing it was unpredicated).
>
> Sent from my phone
> On Sep 7, 2012 11:20 AM, "Krystal Mo" <krystal.mo at oracle.com> wrote:
>
>>  +1 with Nils.
>>
>> Running the test case with -XX:-OptimizeFill works around the problem;
>> running again, this time with -XX:+TraceOptimizeFill, shows:
>>
>> $ ~/testjdk/hotspot-comp/bin/java -XX:-TieredCompilation
>> -XX:+TraceOptimizeFill -XX:+PrintCompilation Test7196857
>>     194    1             java.util.Arrays::fill (21 bytes)
>>     195    1 %           Test7196857::main @ 89 (162 bytes)
>> fill intrinsic for:
>>  111    StoreI    ===  138  131  109  11  [[ 124  131 ]]
>> @int[int:>=0]:exact+any *, idx=5;  Memory: @int[int:>=0]:NotNull:exact+any
>> *, idx=5; !jvms: Arrays::fill @ bci:13
>> fill intrinsic for:
>>  463    StoreI    ===  537  442  461  20  [[ 509  442 ]]
>> @int[int:>=0]:exact+any *, idx=6;  Memory: @int[int:10]:NotNull:exact+any
>> *, idx=6; !orig=[500],488,[486],[111] !jvms: Arrays::fill @ bci:13
>> Test7196857::main @ bci:83
>> Eliminated zeroing in allocation
>> not fill intrinsic candidate: variant store value
>>     219    1 %           Test7196857::main @ -2 (162 bytes)   made not
>> entrant
>> Exception in thread "main" java.lang.RuntimeException: Array just after
>> allocation: [-1163019586, -1163019586, -1163019586, -1163019586,
>> -1163019586, -1163019586, -1163019586, -1163019586, -1163019586,
>> -1163019586]
>>     at Test7196857.main(Test7196857.java:11)
>>
>> Notice "Eliminated zeroing in allocation", which is caused by the missing
>> check that Nils mentioned.
>>
>> - Kris
>>
>> On 09/07/2012 10:11 PM, Nils Eliasson wrote:
>>
>> The bug reproduces with a fill or a corresponding zeroing for loop. But
>> not without. So the bug is that there should be a check of uses between the
>> allocation and the fill (or that the check is incomplete).
>>
>> //Nils
>>
>> Vitaly Davidovich skrev 2012-09-07 15:24:
>>
>> Dan,
>>
>> I've cc'd compiler dev and removed hotspot dev as this looks like a
>> compiler issue.  Hope you don't mind.
>>
>> My hunch is that the Arrays.fill() is tripping this up - is it
>> reproducable if fill() is removed?
>>
>> Sent from my phone
>> On Sep 7, 2012 8:39 AM, "Dan Hicks" <danhicks at fastmail.fm> wrote:
>>
>>> This bug has come to my attention:
>>> http://stackoverflow.com/questions/12317668/java-int-array-initializes-with-nonzero-elements
>>>
>>> Basically there is a reproducible (by several people) situation where a
>>> new int array is not zeroed.  The author reports the error is reproducible
>>> on HotSpot 64-bit server VM, Java version from 1.7.0_04 to 1.7.0_10 on
>>> Gentoo Linux, Debian Linux (both kernel 3.0 version) and MacOS Lion.  (Not
>>> tested on 32-bit or Windows.)
>>>
>>> Reportedly bug7196857 has been filed with Oracle.
>>>
>>> --
>>> Dan Hicks
>>> Nothing makes us so lonely as our secrets.  --Paul Tournier
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120907/1aaef8c8/attachment.html