(original) (raw)

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