3

If I run the following code with the -XX:+UseG1GC flag, every couple of runs the cellSize_m variable will get set to 0 inside the loop and I'll get the "Now it's broken" printouts. What am I missing here?

public class BugTest
{
  public static void main(String[] args)
  {
    fillArray(20);
  }

  public static void fillArray(double cellSize)
  {
    final double cellSize_m = cellSize;
    Integer[] hemispheres = new Integer[565504];

    for (int i = 0; i < 565504; i++)
    {
      hemispheres[i] = i;
      if (cellSize_m == 0)
      {
        System.out.println("Now it's broken. Iteration: " + i + " " + cellSize_m);
      }
    }
    System.out.println("Incrementing Cell Size " + (cellSize_m + 1));
  }
}

I'm on windows 7 using 64bit Java 8 build 144.

brainchrist
  • 184
  • 2
  • 8
  • 1
    You sure it's the GC and not some runtime compilation that causes it? Doesn't make much sense for a GC to reset primitive stack values that never reach heap – Vince Aug 10 '17 at 16:42
  • I'm not sure of the cause at all. I just can't reproduce it if I turn the GC flag off. I'm not an expert of the inner workings of the JVM by any means, I'm just trying to figure out why this code runs in a way I didn't expect it to. – brainchrist Aug 10 '17 at 16:43
  • I'll test it out once I'm on a computer. Could you please post the [verbose](http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmpt) information? It may also help to post [JIT compilation logs](http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html) (scroll down to *Full Logging of JIT Compilation*) – Vince Aug 10 '17 at 19:02
  • [JIT log](https://pastebin.com/fKJ1zQVN) and [console output with verbose options](https://pastebin.com/idZtgyFa) – brainchrist Aug 10 '17 at 19:15
  • 1
    Yeah, seems like a bug. Running with `-Xcomp` removes the problem, and can't seem to reproduce the problem without the `-XX:+UseG1GC` flag. I recommend posting a [bug report](https://bugs.openjdk.java.net/secure/Dashboard.jspa) – Vince Aug 10 '17 at 22:59
  • Thanks for looking into it – brainchrist Aug 10 '17 at 23:29
  • [JDK-8186112 was opened to address this problem](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186112) – brainchrist Aug 11 '17 at 14:17
  • 1
    Good to know. I'm going to be writing a detailed answer soon. It seems to be an issue with OSR (On Stack Replacement) mixed with Escape Analysis. OSR's purpose is to replace currently running loops with a more optimized version of the loop, all while that loop is executing (sneaks in the changes on the next iteration it can). Escape Analysis looks at reachability in hopes to perform some *crazy* optimizations that would dramatically boost speed, at the cost of totally restructuring the instructions (possibly removing some). Due to the strange nature of `cellSize_m`, you confused the compiler – Vince Aug 11 '17 at 17:15

2 Answers2

1

I have reported a similar bug JDK-8165766 last year, but it doesn't seem Oracle eager to fix this over optimization issue caused G1GC failed on floating point computation.

  • Yeah it looks like the root issue is fixed in Java 9, but nobody every completed the [backport issue](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8152757) for java 8. – brainchrist Aug 30 '17 at 21:12
0

It seems to be a jdk bug. JDK-8186112

brainchrist
  • 184
  • 2
  • 8