Inlining doesn't respect JPMS access restrictions

[szeiger]

The Scala optimizer respects Java access modifiers so it doesn't inline any code that needs to call other code which is not accessible at the call site. This is not the case for JPMS restrictions. For example, running on OpenJDK 11 with -opt:l:inline -opt-inline-from:**:

Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 11.0.5).
Type in expressions for evaluation. Or try :help.

scala> "".toDouble
java.lang.IllegalAccessError: class  (in unnamed module @0x69b88f85) cannot access class jdk.internal.math.FloatingDecimal (in module java.base) because module java.base does not export jdk.internal.math to unnamed module @0x69b88f85
  ... 36 elided

This happens because the String:toDouble implementation from the JDK gets inlined into user code even though it cannot access jdk.internal.math.FloatingDecimal from outside the JDK.

(It's probably a bad idea to inline from the JDK in the first place but the problem will become more pronounced as more and more libraries make use of Java Modules, too.)

[SethTisue]

@lrytz want to milestone this?

[lrytz]

We don't have the infrastructure in place to check module access restrictions, so this is on hold until then.

$> java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)
$> scala
Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 11.0.4).
Type in expressions for evaluation. Or try :help.

scala> jdk.internal.math.FloatingDecimal.parseDouble("1")
java.lang.IllegalAccessError: class  (in unnamed module @0x74fab04a) cannot access class jdk.internal.math.FloatingDecimal (in module java.base) because module java.base does not export jdk.internal.math to unnamed module @0x74fab04a
  ... 28 elided

[lrytz]

(Related to scala/scala-dev#529)

[szeiger]

Another angle when inlining from the JDK: There should probably be a default exclusion list for classes with intrinsics. You don't want to accidentally inline from an intrinsic method that could be replaced by HotSpot with a native machine instruction. The resulting code will still work but it will run much slower.

[lrytz]

Good point; how can we find out what parts of the JDK the VMs intrinsify?