Compiler loops forever in FixReadsPhase

[ninja-]

I am compiling a whitelisted list of methods, some from my jar and some from java.base.
Using jaotc --compile-for-tiered --ignore-errors
After doing most of the work compiler freezes forever with this stacktrace..

"pool-1-thread-1" #14 prio=5 os_prio=0 cpu=808163.07ms elapsed=832.57s tid=0x00007fe0412b6800 nid=0x279 runnable  [0x00007fe000b34000]
   java.lang.Thread.State: RUNNABLE
	at org.graalvm.compiler.phases.common.FixReadsPhase$RawConditionalEliminationVisitor.processEnd(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:313)
	at org.graalvm.compiler.phases.common.FixReadsPhase$RawConditionalEliminationVisitor.processNode(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:225)
	at org.graalvm.compiler.phases.common.FixReadsPhase$RawConditionalEliminationVisitor.enter(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:485)
	at org.graalvm.compiler.phases.common.FixReadsPhase$RawConditionalEliminationVisitor.enter(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:139)
	at org.graalvm.compiler.nodes.cfg.ControlFlowGraph.visitDominatorTreeDefault(jdk.internal.vm.compiler@12.0.2/ControlFlowGraph.java:132)
	at org.graalvm.compiler.nodes.cfg.ControlFlowGraph.visitDominatorTree(jdk.internal.vm.compiler@12.0.2/ControlFlowGraph.java:292)
	at org.graalvm.compiler.phases.common.FixReadsPhase.run(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:518)
	at org.graalvm.compiler.phases.common.FixReadsPhase.run(jdk.internal.vm.compiler@12.0.2/FixReadsPhase.java:86)
	at org.graalvm.compiler.phases.BasePhase.apply(jdk.internal.vm.compiler@12.0.2/BasePhase.java:197)
	at org.graalvm.compiler.phases.BasePhase.apply(jdk.internal.vm.compiler@12.0.2/BasePhase.java:139)
	at org.graalvm.compiler.phases.PhaseSuite.run(jdk.internal.vm.compiler@12.0.2/PhaseSuite.java:212)
	at org.graalvm.compiler.phases.BasePhase.apply(jdk.internal.vm.compiler@12.0.2/BasePhase.java:197)
	at org.graalvm.compiler.phases.BasePhase.apply(jdk.internal.vm.compiler@12.0.2/BasePhase.java:139)
	at org.graalvm.compiler.core.GraalCompiler.emitFrontEnd(jdk.internal.vm.compiler@12.0.2/GraalCompiler.java:266)
	at org.graalvm.compiler.core.GraalCompiler.compile(jdk.internal.vm.compiler@12.0.2/GraalCompiler.java:180)
	at org.graalvm.compiler.core.GraalCompiler.compileGraph(jdk.internal.vm.compiler@12.0.2/GraalCompiler.java:165)
	at jdk.tools.jaotc.AOTBackend.compileGraph(jdk.aot@12.0.2/AOTBackend.java:142)
	at jdk.tools.jaotc.AOTBackend.compileMethod(jdk.aot@12.0.2/AOTBackend.java:104)
	at jdk.tools.jaotc.AOTCompilationTask.run(jdk.aot@12.0.2/AOTCompilationTask.java:122)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@12.0.2/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@12.0.2/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@12.0.2/Thread.java:835)

EDIT: turns out it's caused by one of jars on classpath from our vendor that's obfuscated by some shitty heavy obfuscator. I blacklisted it and now it compiles. - Graal bails out from compiling most of it's classes with different errors, but looks like there's still one that can confuse it. Would be nice to get it fixed anyway.

[dougxc]

Please open an OpenJDK bug for jaotc issues. (cc @veresov )

[ninja-]

It's not a bug in jaotc as you can see in stacktrace. It's a bug in Graal version shipped in latest JDK

[dougxc]

jaotc executes Graal in a mode different from JIT compilation and so I believe this is most likely jaotc specific behavior. Since jaotc is an OpenJDK tool, you may get a quicker resolution filing a bug with that project. Also, the version of Graal in JDK 12 is quite old compared to the latest sources on GitHub.

One thing you could try is to reproduce this from within the Graal repo:

> cd compiler
compiler> export JAVA_HOME=/path/to/jdk11
compiler> mx build
compiler> mx jaotc ...

[thomaswue]

This could be more general though. Looks a bit like some very degenerated control flow. Is there any chance you could make a compiler graph available for this method (via -Dgraal.MethodFilter=Foo.bar -Dgraal.Dump=:2)? Also, can you post multiple of those stack traces so one can see where it loops. Maybe running with "-esa -ea" gives additional insights as well.

[ninja-]

Also, can you post multiple of those stack traces so one can see where it loops.

Stacktrace does not change. Probably it's not exiting the while loop.
I'll try to get additional debugs later.