Array not zeroed on creation (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Fri Sep 7 08:50:50 PDT 2012

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.004 to 1.7.010 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

More information about the hotspot-compiler-dev mailing list