Array not zeroed on creation

[Krystal Mo]

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 
> <mailto: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
>>>     <mailto: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/9f8505c3/attachment.html