Make MODULE$ Final Again?

[retronym]

We had to (#194) make the module field non-final to prepare for JDK9/Classfile 53 verifier, which enforces the (long standing) rule that static final field assignments must occur in <clinit> (not <init>).

However, this prevents the JIT from eliding the access of this field in calling code. For example, in scala.math.max(1, 2), the JIT can't rule out that scala.math.package$.MODULE$ hasn't been nulled out, so it must be checked.

For some special cases, like above, I've managed to restore finality of that field in scala/scala#6523. But important modules don't qualify for the optimization, e.g Predef and Nil.

The JDK has an internal annotation, @Stable, that would tell the JIT that this field is 'effectively final', ie it is assign once. That's not available for our purposes. It can be simulated with invokedynamic, which might be worth trying, but we need to ensure it is really zero-overhead across different JDK versions.

Another idea came to mind yesterday.

Given:

trait T {
  println("T")
}
class C {
  println("C")
}
object O extends C with T {
  println("body")
}

We currently emit:

public final class O$ extends C  implements T  {

  public static LO$; MODULE$

  public static <clinit>()V
    NEW O$
    INVOKESPECIAL O$.<init> ()V
    RETURN

  private <init>()V
    ALOAD 0
    INVOKESPECIAL C.<init> ()V
    ALOAD 0
    PUTSTATIC O$.MODULE$ : LO$;
    ALOAD 0
    INVOKESTATIC T.$init$ (LT;)V (itf)
    GETSTATIC scala/Predef$.MODULE$ : Lscala/Predef$;
    LDC "body"
    INVOKEVIRTUAL scala/Predef$.println (Ljava/lang/Object;)V
    RETURN
}

But why not:

public final class O$ extends C  implements T  {

  public static final LO$; MODULE$

  public static <clinit>()V
    NEW O$
    DUP
    INVOKESPECIAL O$.<init> ()V
    DUP
    PUTSTATIC O$.MODULE$ : LO$;
    INVOKESPECIAL O$.$init$
    RETURN

  private <init>()V
    ALOAD 0
    INVOKESPECIAL C.<init> ()V

  private $init$()V
    ALOAD 0
    INVOKESTATIC T.$init$ (LT;)V (itf)
    GETSTATIC scala/Predef$.MODULE$ : Lscala/Predef$;
    LDC "body"
    INVOKEVIRTUAL scala/Predef$.println (Ljava/lang/Object;)V

}

ie, split the constructor up just after the super-class constructor call and move the rest into a private method that would be called after <clinit> assigns the module field.

[retronym]

@lrytz @adriaanm WDYT?

One incompatibility is that reflectively instantiating the module's private constructor (either nefariously or accidentally with help from a misconfigured framework like kryo) would no longer get a fully initialized instance.

[retronym]

/cc @mkeskells @rorygraves

[odersky]

If we put the actual module initialization in a private method, would that not break the definite assignment rules for final fields in the object? I believe that's the case for Java the language, but I am not sure to what degree the JVM enforces it.

[retronym]

@odersky You're right. It was too good to be true!

The update to the verifier in question here, that prevents static final assignment outside of <clinit>, also enforces the rule that non-static final fields can only be assigned in <init>. In fact, we're about to change the trait encoding to make mixin final vals non-final in bytecode (we'll add an explicit memory barrier to fill in for the implicit one that the JVM would have inserted thanks to the final field).

It is worth noting the class-file version dependent treatment of non-conformant classfiles in JDK9+:

• If the classfile version is 53 or higher, its a verify error
• otherwise, JIT disables the FoldStableValues optimizations anyway, ignoring the final modifier.

@mkeskells showed the effect that JIT optimizations can make: rorygraves/scalac_perf#32 (comment)

That suggests scala.math.min seems to be 17% slower than the underlying Math.min that is forwards to, which can be recovered with a final module field.

[viktorklang]

@retronym Is there a difference CONDY would make here?

[retronym]

It isn't exactly a constant because the null value can be observed from the superclass.

class C {
  println("O = " + O)
}

object O extends C

object Main extends App {
  O.toString
  new C
}

$ scalac /tmp/test.scala && scala Main
O = null
O = O$@7d6f77cc

We could, however, use InvokeDynamic to intermediate the access to the module field with a bootstrap method that collapses into a ConstantCallSite as soon as the first non-null value of the field is witnessed. This idea is implemented in a general purpose way in https://github.com/forax/exotic#stablefield---javadoc.

That's worth trying, but does require some care as we'd be using the technique very widely and we need a high degree of certainty that it behaves and performs as we'd like in all environments.

[viktorklang]

@retronym I'd be extremely interested in hearing about how INDY usage for this would work out. If you do pursue it, please let me know.

[mkeskells]

@viktorklang FYI - I had a couple of experements with Reme exotics library https://github.com/forax/exotic and the performance is very different in different VMs (tested JDK 8,9,10). Depends on the technique though

[fwbrasil]

FIY the fact that the modules are not final anymore also breaks constant folding in Graal (see oracle/graal#637). @dougxc mentioned that in Java 11 Dynamic Constants might be an alternative to solve this problem.

[retronym]

From oracle/graal#637 (comment)

Here is a short summary of the solution that @gilles-duboscq came up with - objects that assign to their ACC_FINAL could instead put that state into static fields. That way, any singleton constructor could be emitted inside the .

The singleton object fields (whether ACC_FINAL or not) are anyway accessed through accessors, so it seems like the entire singleton object state be kept in static fields. Serialization also already makes sure that the singleton object does not get duplicated.
Other than various reflection-reliant libraries, what else could such a change affect?

[retronym]

This seems like a good solution to me. The bonus benefit is that fields of objects would themselves be constant foldable, without relying on -XX:+TrustNonStaticFinalFields. A canonical use case would be declaring static final MethodHandle constants.

We're too late in the Scala 2.13 cycle to introduce this encoding. But it would be great for the next version.

[smarter]

What does "assign to their ACC_FINAL" mean ? Could you sketch what the bytecode would look like with this proposal ?