Default Scala threadpool fails to initialize under 20.2 while 20.1 works perfectly

[pshirshov]

I'm getting the following stacktrace on native-image 20.2 when my Scala application tries to execute ExecutionContext.global:

Exception in thread "main" com.oracle.svm.core.jdk.UnsupportedFeatureError: Invoke with MethodHandle argument could not be reduced to at most a single call or single field access. The method handle must be a compile time constant, e.g., be loaded from a static final field. Method that contains the method handle invocation: java.lang.invoke.LambdaForm$MH/310739890.invoke_MT(Object, Object)
at com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:86)
at scala.runtime.Statics.releaseFence(Statics.java:148)
at scala.concurrent.impl.ExecutionContextImpl$$anon$3.<init>(ExecutionContextImpl.scala:101)
at scala.concurrent.impl.ExecutionContextImpl$.fromExecutor(ExecutionContextImpl.scala:101)
at scala.concurrent.ExecutionContext$.global$lzycompute(ExecutionContext.scala:142)
at scala.concurrent.ExecutionContext$.global(ExecutionContext.scala:142)
...

Exactly the same code works perfectly when built on 20.1.

I have both these lines in my NI arguments:

--initialize-at-build-time=scala
--initialize-at-build-time=scala.runtime.Statics$VM

It happens on both Java 8 and Java 11 versions:

bash-4.2# native-image --version
GraalVM Version 20.2.0 (Java Version 1.8.0_262)

bash-4.2# java -version
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (build 1.8.0_262-b10)
OpenJDK 64-Bit Server VM GraalVM CE 20.2.0 (build 25.262-b10-jvmci-20.2-b03, mixed mode)

bash-4.2# native-image --version
GraalVM Version 20.2.0 (Java Version 11.0.8)

bash-4.2# java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment GraalVM CE 20.2.0 (build 11.0.8+10-jvmci-20.2-b03)
OpenJDK 64-Bit Server VM GraalVM CE 20.2.0 (build 11.0.8+10-jvmci-20.2-b03, mixed mode, sharing)

[munishchouhan]

@pshirshov Please share the reproducer for the reported error.

[pshirshov]

https://github.com/pshirshov/graalvm202-scala-fence-bug

[shelajev]

This is a known thing in Scala 2.13 where Statics.VM uses methodhandles, for example scala/bug#11634.

I think if you add the scalameta jar with the correct substitutions and initialize Statics.VM at build time, it should work as expected:

diff --git a/build.sbt b/build.sbt
index 1615cce..2e5a252 100644
--- a/build.sbt
+++ b/build.sbt
@@ -14,9 +14,12 @@ graalVMNativeImageOptions ++= Seq(
   "--enable-https",
   "--enable-http",
   "--enable-all-security-services",
-  "--initialize-at-build-time=scala,testpkg"
+  "--initialize-at-build-time=scala,scala.runtime.Statics"
 )

 libraryDependencies += "org.graalvm.nativeimage" % "svm" % "20.2.0" % Provided
+libraryDependencies += "org.scalameta" %% "svm-subs" % "20.2.0"

 enablePlugins(GraalVMNativeImagePlugin)

On my machine (I didn't build in Docker) it prints :

./target/graalvm-native-image/graalvm202-scala-fence-bug
scala.concurrent.impl.ExecutionContextImpl$$anon$3@7f0a50301bf8[Running, parallelism = 16, size = 0, active = 0, running = 0, steals = 0, tasks = 0, submissions = 0]

[pshirshov]

It works well on 20.1, so I'm not sure if it's really just a Scala issue. Thanks for the workaround though, I'll try it.

[pshirshov]

Upd: the workaround works. Though I believe it still a good idea to investigate why did it work before 20.2.

[cstancu]

The underlying issue here is incomplete MethodHandle support. That is under development and is being tracked by #2761.