eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k stars 720 forks source link

The nightly build (jdk-9+181-20 on January 22 2018) has different behaviors on Xcomp and default mode. #997

Open tianxiaogu opened 6 years ago

tianxiaogu commented 6 years ago

The nightly build (jdk-9+181-20 on January 22 2018 Linux x64) has different behaviors on Xcomp and default mode.

C0.class

Default: A NegativeArraySizeException is thrown

Xcomp: exit normally with 0

$ ./jdk-9+181/bin/java -Xcomp C0
$ echo $?
0
$ ./jdk-9+181/bin/java C0
Exception in thread "main" java.lang.NegativeArraySizeException
    at C0.main(Unknown Source)
$ ./jdk-9+181/bin/java --version
openjdk 9-internal
OpenJDK Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk)
Eclipse OpenJ9 VM (build 2.9, JRE 9 Linux amd64-64 Compressed References 20180122_95 (JIT enabled, AOT enabled)
OpenJ9   - d38352e
OMR      - cfd2f17
OpenJDK  - be5903d based on jdk-9+181)

The head of OpenJDK throws an exception.

$ ./openjdk/jdk/build/linux-x86_64-normal-server-release/jdk/bin/java -Xcomp C0
Exception in thread "main" java.lang.NegativeArraySizeException
    at C0.main(Unknown Source)
$ ./openjdk/jdk/build/linux-x86_64-normal-server-release/jdk/bin/java -version
openjdk version "10-internal" 2018-03-20
OpenJDK Runtime Environment (build 10-internal+0-adhoc.t.jdk)
OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.t.jdk, mixed mode)

Oracle JDK 9 throws an exception.

$ ./jdk-9.0.4/bin/java -Xcomp C0
Exception in thread "main" java.lang.NegativeArraySizeException
    at C0.main(Unknown Source)
$ ./jdk-9.0.4/bin/java -version
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

OpenJDK 8 also throws an exception.

$ java C0
Exception in thread "main" java.lang.NegativeArraySizeException
    at C0.main(Unknown Source)
$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
pshipton commented 6 years ago

-Xcomp is mapped to -Xjit:count=0

The OpenJDK definition is -Xcomp forces compilation of methods on first invocation

tianxiaogu commented 6 years ago

@pshipton Thanks for your reply. I am not sure whether this is a bug or not. I have attached the program C0.class (via Google Drive) now.

BTW, C0.class is generated by a fuzzing tool I created. So I cannot provide its source code.

mstoodle commented 6 years ago

@andrewcraik i wonder if you or your delegate would like to take a look at this one?

tianxiaogu commented 6 years ago

@andrewcraik Sorry, this may not be an issue. It seems that the optimization of OpenJ9 removes the unused allocation, while HotSpot does not.

The JVM specification specifies that anewarray and newarray should throw a NegativeSizeException if the size is negative. Removing unused array allocation may break the specification of JVM.

https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.anewarray

JamesKingdon commented 6 years ago

Thanks for the interesting test case @tianxiaogu This may need some thought.

Trivial cases have the expected behaviour, e.g.

      short s = -1;
      double[] da = new double[s];

gives the expected Exception in thread "main" java.lang.NegativeArraySizeException However, a conversion chain on the size prevents the JIT from realizing that an exception will always be thrown, and then the allocation of the unused array gets optimized away:

public class NegArrayRepro
{
   public static void main(String[] args)
   {
      float a = -1.0f;
      int i = (int) a;
      short s = (short) i;
      double[] da = new double[s];

      System.out.println("done, with s "+s);
   }
}

results in

java -Xcomp NegArrayRepro 
done, with s -1
andrewcraik commented 6 years ago

@JamesKingdon interesting - the main issue will likely be that we can't tell that the float is negative. A compile log will be necessary. It would be good to confirm the opt level this failed at and, if it is a cold compile, see what happens in the warm compile. Regardless, there is a bug to be fixed here.

JamesKingdon commented 6 years ago

Compilation was at warm, I will attach the log. The newarray was eliminated at line 1508 by deadTreesElimination. main.log.txt

DanHeidinga commented 6 years ago

@JamesKingdon / @andrewcraik Any updates on this?

JamesKingdon commented 6 years ago

Hi Dan, nothing to the best of my knowledge.