Boxing code generated by opaque types

[erikerlandson]

(this started as #12009, but is maybe better suited for a discussion than an issue)

scala

I'm working with scala-3.0.0-RC2.

minimal example

Consider this simplified opaque type (Wrap) that uses a typeclass to implement operator + logic.

trait Addable[V]:
    def plus(x: V, y: V): V
object Addable:
    given Addable[Int] with
        inline def plus(x: Int, y: Int): Int = x + y

import wrap.Wrap
extension[V](lhs: Wrap[V])
    inline def +(rhs: Wrap[V])(using va: Addable[V]): Wrap[V] =
        Wrap(va.plus(lhs.value, rhs.value))

object wrap:
    opaque type Wrap[V] = V
    object Wrap:
        def apply[V](v: V): Wrap[V] = v

    extension[V](w: Wrap[V])
        def value: V = w

object testwrap:
    import wrap.*
    val p = Wrap(3) + Wrap(5)

output

If I compile this code, and then look at the byte-code for object testwrap, I see the following. It is clear from the byte-code that Wrap is being stored as a raw Int (nice), and the inlined type-class compiles down to raw iadd (also nice). However, the code also invokes quite a lot of boxing and unboxing, and I am trying to work out the trade-off in compute cost from the (un)boxing versus efficiency of storing the raw Int.

$ javap -c .../testwrap$.class

  public static {};
    Code:
       0: new           #2                  // class coulomb/testwrap$
       3: dup
       4: invokespecial #23                 // Method "<init>":()V
       7: putstatic     #25                 // Field MODULE$:Lcoulomb/testwrap$;
      10: getstatic     #28                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      13: iconst_3
      14: invokestatic  #34                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
      17: invokevirtual #38                 // Method coulomb/wrap$Wrap$.apply:(Ljava/lang/Object;)Ljava/lang/Object;
      20: invokestatic  #42                 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
      23: istore_0
      24: getstatic     #28                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      27: iconst_5
      28: invokestatic  #34                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
      31: invokevirtual #38                 // Method coulomb/wrap$Wrap$.apply:(Ljava/lang/Object;)Ljava/lang/Object;
      34: invokestatic  #42                 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
      37: istore_1
      38: getstatic     #28                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      41: getstatic     #47                 // Field coulomb/wrap$.MODULE$:Lcoulomb/wrap$;
      44: iload_0
      45: invokestatic  #34                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
      48: invokevirtual #50                 // Method coulomb/wrap$.value:(Ljava/lang/Object;)Ljava/lang/Object;
      51: invokestatic  #42                 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
      54: istore_2
      55: getstatic     #47                 // Field coulomb/wrap$.MODULE$:Lcoulomb/wrap$;
      58: iload_1
      59: invokestatic  #34                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
      62: invokevirtual #50                 // Method coulomb/wrap$.value:(Ljava/lang/Object;)Ljava/lang/Object;
      65: invokestatic  #42                 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
      68: istore_3
      69: iload_2
      70: iload_3
      71: iadd
      72: invokestatic  #34                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
      75: invokevirtual #38                 // Method coulomb/wrap$Wrap$.apply:(Ljava/lang/Object;)Ljava/lang/Object;
      78: invokestatic  #42                 // Method scala/runtime/BoxesRunTime.unboxToInt:(Ljava/lang/Object;)I
      81: putstatic     #52                 // Field p:I
      84: return

  public int p();
    Code:
       0: getstatic     #52                 // Field p:I
       3: ireturn

Expectation

I'm not sure what a realistic expectation is, but I was hoping the compiler could elide the boxing/unboxing, since the only semantically necessary operations are istore, iload and iadd on the underlying raw Int values.

I am also unsure how much the various calls to the boxing methods cost. They appear to be significant relative to the core integer operations, however I do not know exactly how much.

[nicolasstucki]

It looks like all the boxing comes from the generic parameter V and not the opaque type. All instances of V will be erased to Object and therefore will box.

[erikerlandson]

adding specialization improves the situtation for sure:

public final class coulomb.testwrap$ implements java.io.Serializable {
  public static final coulomb.testwrap$ MODULE$;

  public static {};
    Code:
       0: new           #2                  // class coulomb/testwrap$
       3: dup
       4: invokespecial #21                 // Method "<init>":()V
       7: putstatic     #23                 // Field MODULE$:Lcoulomb/testwrap$;
      10: getstatic     #26                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      13: iconst_3
      14: invokevirtual #30                 // Method coulomb/wrap$Wrap$.apply:(I)I
      17: istore_1
      18: getstatic     #26                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      21: iconst_5
      22: invokevirtual #30                 // Method coulomb/wrap$Wrap$.apply:(I)I
      25: istore_2
      26: getstatic     #26                 // Field coulomb/wrap$Wrap$.MODULE$:Lcoulomb/wrap$Wrap$;
      29: getstatic     #35                 // Field coulomb/wrap$.MODULE$:Lcoulomb/wrap$;
      32: iload_1
      33: invokevirtual #38                 // Method coulomb/wrap$.value:(I)I
      36: istore_3
      37: getstatic     #35                 // Field coulomb/wrap$.MODULE$:Lcoulomb/wrap$;
      40: iload_2
      41: invokevirtual #38                 // Method coulomb/wrap$.value:(I)I
      44: istore        4
      46: iload_3
      47: iload         4
      49: iadd
      50: invokevirtual #30                 // Method coulomb/wrap$Wrap$.apply:(I)I
      53: istore_0
      54: return
}

[erikerlandson]

It's hard to improve on that without inlining Wrap.apply() and value, which the compiler does not allow for opaque types.

I think getting inline to work on opaque types, and/or some kind of special annotation @pureLift, would be cool, assuming it's feasible.

[erikerlandson]

BTW, the specialized code looks like:

trait Addable[V]:
    def plus(x: V, y: V): V
object Addable:
    given Addable[Int] with
        inline def plus(x: Int, y: Int): Int = x + y

import wrap.Wrap
extension[V](lhs: Wrap[V])
    inline def +(rhs: Wrap[V])(using va: Addable[V]): Wrap[V] =
        Wrap(va.plus(lhs.value, rhs.value))
extension(lhs: Wrap[Int])
    inline def +(rhs: Wrap[Int])(using va: Addable[Int]): Wrap[Int] =
        Wrap(va.plus(lhs.value, rhs.value))

object wrap:
    opaque type Wrap[V] = V
    object Wrap:
        def apply[V](v: V): Wrap[V] = v
        def apply(v: Int): Wrap[Int] = v

    extension[V](w: Wrap[V])
        def value: V = w
    extension(w: Wrap[Int])
        def value: Int = w

object testwrap:
    import wrap.*
    private val p = Wrap(3) + Wrap(5)

[erikerlandson]

@johnynek is the above what you meant by specializing?

[nicolasstucki]

Yes, that is the kind of specialization I had in mind.