Array not zeroed on creation
Vitaly Davidovich
vitalyd at gmail.com
Fri Sep 7 08:30:22 PDT 2012
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/f874f82a/attachment-0001.html
More information about the hotspot-compiler-dev
mailing list