JDK-8211179 : [Graal] org.graalvm.compiler.core.test.CountedLoopTest fails with NullPointerException
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-09-26
  • Updated: 2019-09-13
  • Resolved: 2018-12-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12Resolved
Related Reports
Duplicate :  
JDK-8214023 - Update Graal
Relates :  
JDK-8199885 - [Graal] org.graalvm.compiler.core.test.CountedLoopTest fails with "ControlFlowAnchor should never be cloned in the same graph"
Description
After fixing JDK-8199885 org.graalvm.compiler.core.test.CountedLoopTest  still continues to fail but with java.lang.NullPointerException.

Here is example of failed log:
There was 1 failure:
1) increment7(org.graalvm.compiler.core.test.CountedLoopTest)
java.lang.NullPointerException
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.loop.BasicInductionVariable.isConstantExtremum(BasicInductionVariable.java:174)
        at org.graalvm.compiler.core.test.CountedLoopTest$IVPropertyNode.rewrite(CountedLoopTest.java:417)
        at org.graalvm.compiler.core.test.CountedLoopTest.checkHighTierGraph(CountedLoopTest.java:487)
        at org.graalvm.compiler.core.test.GraalCompilerTest$2.run(GraalCompilerTest.java:287)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.Phase.run(Phase.java:49)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:197)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:139)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.PhaseSuite.run(PhaseSuite.java:212)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:197)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:139)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.core.GraalCompiler.emitFrontEnd(GraalCompiler.java:256)
        at jdk.internal.vm.compiler@12-internal/org.graalvm.compiler.core.GraalCompiler.compile(GraalCompiler.java:180)
        at org.graalvm.compiler.core.test.GraalCompilerTest.compile(GraalCompilerTest.java:1060)
        at org.graalvm.compiler.core.test.GraalCompilerTest.getCode(GraalCompilerTest.java:957)
        at org.graalvm.compiler.core.test.GraalCompilerTest.getCode(GraalCompilerTest.java:898)
        at org.graalvm.compiler.core.test.GraalCompilerTest.executeActual(GraalCompilerTest.java:734)
        at org.graalvm.compiler.core.test.GraalCompilerTest.executeActualCheckDeopt(GraalCompilerTest.java:866)
        at org.graalvm.compiler.core.test.GraalCompilerTest.testAgainstExpected(GraalCompilerTest.java:856)
        at org.graalvm.compiler.core.test.GraalCompilerTest.testAgainstExpected(GraalCompilerTest.java:852)
        at org.graalvm.compiler.core.test.GraalCompilerTest.test(GraalCompilerTest.java:821)
        at org.graalvm.compiler.core.test.GraalCompilerTest.test(GraalCompilerTest.java:790)
        at org.graalvm.compiler.core.test.GraalCompilerTest.test(GraalCompilerTest.java:783)
        at org.graalvm.compiler.core.test.CountedLoopTest.testCounted(CountedLoopTest.java:503)
        at org.graalvm.compiler.core.test.CountedLoopTest.increment7(CountedLoopTest.java:161)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
Comments
Yes it's included in the last Graal update as GR-12760.
12-12-2018
Hi [~never], Request help. Please confirm if this bug can be closed as duplicate of recent JDK-8214023 Graal Update?
11-12-2018
sca00mlf.us.oracle.com isn't a machine I appear to have access to. For whatever reason it needs -XX:+UseJVMCICompiler to reproduce for me but I can believe that it's really a timing issue. That would actually make more sense to me. I think these tests should be run without using profiling information which I think is the source of problem.
28-11-2018
It's definitely still reproducible. I just used latest graal with our JDK8 to investigate it.
28-11-2018
well, the original issue was seen with disabled UseJVMCICompiler (which is the mode suggested to run unit tests in). I will see if I still can reproduce the issue with latest jdk12.
28-11-2018
I can reproduce it with fastdebug graal-jvmci-8 though it's not totally reliable. mx unittest --verbose -XX:+UseJVMCICompiler org.graalvm.compiler.core.test.Counted#increment8 When it fails we've compiled the loop body with a FixedGuard for UnreachedCode for the loop exit. So the loop appears to be infinite instead of having an exit. I think this is just a bad interaction with running the test with -XX:+UseJVMCICompiler. I'm not sure what the right workaround is though.
28-11-2018
It appears that using fastdebug bits is required as is using -XX:+UseJVMCICompiler. For some reason the increment8 case isn't a counted loop under those conditions.
28-11-2018
[~gdub] can you please have a look into this.
27-09-2018
Doug, could you please have a look or re-assign? Thanks.
27-09-2018
ILW = NPE during Graal compilation, single test with Graal as JIT, use C2 = HLM = P3
27-09-2018
Note, the issue is not reproduced on all machines. For example I can't reproduce it on my linux but I was able to easy reproduce it on one of mach5 machine. I will provide instructions how to reproduce soon.
26-09-2018