(original) (raw)

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