Optionally use VarHandles for Lazy Vals when targeting JDK 9+ #637
Conversation
…ased on scala#24109 implementation if targeting JDK 9 or later
WojciechMazur
changed the title
| @tu lazy val MethodHandlesClass: TermSymbol = requiredModule("java.lang.invoke.MethodHandles") | ||
| @tu lazy val MethodHandles_lookup: Symbol = MethodHandlesClass.requiredMethod("lookup") |
There was a problem hiding this comment.
No need to explicitlly guard these on JDK8: their usage is not reachable on JDK8
| // Check if environment allows VarHandles, cached per run | ||
| private var canUseVarHandles: Boolean = compiletime.uninitialized | ||
| private var cachedContext: Context = compiletime.uninitialized | ||
| def useVarHandles(using Context) = { |
There was a problem hiding this comment.
There's plenty of usages, the check might allocate on each usage mostly due to .toInt or .toIntOption conversions, so let's skip redundant calculations - unlikely to change
I would definitely not do it implicitly. Just because you build on JDK 9 shouldn't fundamentally change the compilation strategy. For an LTS, even changing the behavior of Consider defining a separate Under a separate option, this seems reasonable. |
Yeah, as much as it would be more future proof if we did this implicitely, but can't do it in the LTS. I think we should announce it as a new option and heavily promote |
3 participants
Backports scala#24109 to LTS 3.3, but also keeps existing offset-based implementation.
VarHandles are used if either explicitly targeting JDK 9+ (using
--java-output-version) or when using implicit releae-versions and using JDK 9When using VarHandles additional static class initializers
<clint>might be generated, where previously these were not needed (see MiMa filter added for scala.Tuple) however, this change is likely a binary compatible. The JVM owns class initialization and there is never an explicit call site to in user bytecode, so link/load will still succeed.