Looking at the PrintCompilation output when running Graal with -Xbatch and -XX:-TieredCompilation shows lots of compilations that time out:

java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:-TieredCompilation -Xbatch -XX:+PrintCompilation -version
[...]
  10704 74 b java.lang.AbstractStringBuilder::isLatin1 (19 bytes) wait for blocking compilation timed out
  20725 75 b sun.nio.fs.UnixPath::normalizeAndCheck (75 bytes) wait for blocking compilation timed out
  30730 76 b sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (489 bytes) wait for blocking compilation timed out
  40734 77 b sun.nio.fs.UnixPath::checkNotNul (16 bytes) wait for blocking compilation timed out
[...]

Douglas Simon:
"This is due to the change in 9 where eager initialization of Graal is later than it is in 8. In 8, Graal is initialized in CompileBroker::compilation_init when BackgroundCompilation is false[1]. This happens before CompileBroker::_initialized is set to true which means no compilations will be enqueued before Graal initialization is complete. When this was ported to JDK 9 (JDK-8145270) it was moved back further due to jigsaw related changes to the startup sequence that caused problems (I can't recall the details) for initializing Graal earlier. The upshot is that compilations can now be enqueued prior to Graal having completed initialization.

I would suggest splitting up CompileBroker::compilation_init into 2 phases. I have attached a patch that does this and appears to work for the -version case."

[1] https://github.com/graalvm/graal-jvmci-8/blob/dc1d526785753e2956add15512800d1ba370210e/src/share/vm/compiler/compileBroker.cpp#L969