Imported From: https://issues.scala-lang.org/browse/SI-9731?orig=1
Reporter: @dwijnand
Affected Versions: 2.11.8

@lrytz said:
i'll take a look, maybe we can do something, either in the frontend or in the optimizer. it would definitely be a valuable improvement for 2.12.

@lrytz said:
Let me quickly outline why this is not straightforward

trait T extends Any {
  def s: String
  def t1 = s.toUpperCase
}

This universal trait needs to be compiled into a valid interface. We don't know that s is potentially implemented as a value class field - in fact, T can be implemented by a non-value class. So the bytecode is

public abstract interface T {
  public abstract s()Ljava/lang/String;

  public default t1()Ljava/lang/String;
    ALOAD 0
    INVOKEINTERFACE T.s ()Ljava/lang/String;
    INVOKEVIRTUAL java/lang/String.toUpperCase ()Ljava/lang/String;
    ARETURN
}

Now we introduce a value class

class C(val s: String) extends AnyVal with T

If we don't want to break separate compilation (change the body of T.t1, re-compile T, also C should get the new impl) then we have no choice but to invoke T.t1, which requires an instance.

Now there's a few possibilities. We can get actually already quite close just with inlining, but it (currently, 2.12.0-M4) requires an @inline annotation:

trait T extends Any {
  def s: String
  @inline final def t1 = s.toUpperCase
}
class C(val s: String) extends AnyVal with T
class A { def f1(c: C) = c.t1 }

gives

public final class C implements T  {
  public f1(Ljava/lang/String;)Ljava/lang/String;
    NEW C
    DUP
    ALOAD 1
    INVOKESPECIAL C.<init> (Ljava/lang/String;)V
    INVOKEINTERFACE T.s ()Ljava/lang/String;
    INVOKEVIRTUAL java/lang/String.toUpperCase ()Ljava/lang/String;
    ARETURN

We're planning to extend our box-unbox optimization to value classes (currently supports tuples and primitive boxes), which would eliminate the allocation. This will probably not happen for 2.12.0, unfortunately - there's not much time left. Note that the JVM's escape analysis will probably also eliminate the box.

Other options I see:

• we could introduce some marker annotation to tell the compiler that def s: String is potentially a value class field. Then we could split up methods that access s into a static method that gets the string as parameter and the instance method that invokes s() and passes it to the static method. the value class could then invoke the static method.
• when generating the value class code, we could locate the bytecode of methods inherited from universal traits and duplicate it, and attempt to create static copies, replacing accesses to this.s() by the value class field. that sounds a bit complicated though, it would have to happen during the optimizer where we can read and duplicate bytecode.

the second of this ideas is related to inlining (code is duplicated), also related to what dimitry is researching for dotty (creating specialized copies of methods).

@lrytz said:
i think the most likely thing that will happen is an improved optimzier that eliminates value class boxes, together with improved inlining heuristics that will inline value class calls in case a box can be eliminated. this was already on my schedule, but after 2.12.0 is out.

@lrytz said:
cc @DarkDimius - i just read on the gitter channel that "Dotty is trying a design that eliminates the allocation" - can you summarize?

@DarkDimius said (edited on Apr 26, 2016 8:37:01 AM UTC):
The basic idea was that universal traits will undergo the same transformation as value classes:

trait StringVal extends Any { def value: String ; final override def toString = value }

becomes

trait StringVal extends Any { def value: String ; final override def toString = StringVal$.toString_extension(this)  }
object StringVal { final override def toString_extension[T <: StringVal](t: T): String = t.value }

This would allow to pass a value class to the value class to the extension method.
Then, I'd have a run of specialization(likely linker-driven on-demand), that would rewrite the code to take a StringVal.

object StringVal { // specialized
  final override def toString_extension[T <: StringVal](t: T): String = t.value 
  final override def toString_extension_spec$1[T = Foo](t: T): String = t.value 
}

This would mean that the normal boxing elimination of value classes would kick-in.

object StringVal {  // erased
  final override def toString_extension(t: StringVal): String = t.value 
  final override def toString_extension_spec$1(t: String): String = Foo$.value_extension(t)
}

David Bouyssie (crumbpicker) said:
In the contributors mailing list I made a suggestion about the possible usage of "sealed traits" to define inheritable extension methods:
https://contributors.scala-lang.org/t/value-classes-and-universal-traits/

This would be a strong requirement but I think it could help to know the list of possible implementations of the universal trait.

Sorry for the late reply.

@lrytz: I understand that it's not possible to anticipate the nature of the different implementations of a given universal trait. But my question was relative to the use of "sealed universal traits". In this context we can determine exactly the list of implementations.
Don't you think it may be helpful regarding the inlining operation?