BoxUnbox

Eliminate box-unbox pairs within method. Such appear commonly after closure elimination:

def t2 = { val f = (b: Byte, i: Int) => i + b // no specialized variant for this function type f(1, 2) // invokes the generic apply }

The closure optimizer re-writes the apply call to anonfun$adapted method, which takes boxed arguments. After inlining this method, we get

def t2 = { val a = boxByte(1) val b = boxInteger(2) val r = boxInteger(anonfun$(unboxByte(a), unboxInt(b))) unboxInt(r) }

All these box/unbox operations are eliminated here.

Implementation: for every box operation, find all consumers of the boxed value, then all producers of these consumers, repeat until reaching a fixpoint. If this results in a set of boxing and unboxing operations, the box can be eliminated.

There are two methods for eliminating boxes: M1: If there is a single boxing operation, the boxed value(s) are stored into new local variable(s) at the allocation site. Accesses to the boxed value are re-written to reads / writes of these locals. Advantages: - supports mutable boxes (IntRef and friends) - supports eliminating unbox operations even if the box object needs to be created because it escapes (see E4) - works by keeping the unboxed value(s) in locals AND the box in its original form - only for immutable boxes: modifications to the escaped box cannot be applied to the local variable(s) holding the boxed value(s). Restriction: - does not work if there are multiple boxing operations (see E1)

M2: If there are multiple boxing operations, the boxing operations are simply eliminated, leaving the unboxed value(s) on the stack. Store / load operations that previously acted on the box are adapted to handle the boxed type(s). If the box contains multiple values (or a size-2 value, which doesn't fit into locals that were used for the box), new local slots are used for store / load operations. Restrictions: - does not support re-writing writes to (mutable) boxes (see E2) - does not support re-writing reads of boxes that also escape (see E3)

E1: M1 only works if there's a single boxing operation. def e1(b: Boolean) = { val i: Integer = box(10) // 10 is stored into a new local, box operation and i removed val j: Integer = box(20) // 20 is stored into a new local, box operation and j removed val r = if (b) i else j // loads and stores of the box are eliminated, r no longer exists unbox(r) // cannot rewrite: we don't know which local to load } Note: the example has no write and the box does not escape, so M2 works here.

E2: mutable boxes with multiple boxing operations cannot be eliminated. M1: see E1 M2: cannot replace an IntRef on the stack by an Int value on the stack, an Int on the stack cannot be modified.

def e2(b: Boolean) = { val r1 = new IntRef(0) val r2 = new IntRef(1) val modRef = if (b) r1 else r2 modRef.elem += 10 // M1: cannot rewrite: which local to write? same as E1. (if (b) r1 else r2).elem += 10 // M2: cannot change an Int on the stack (r1.elem, r2.elem) }

E3: escaping boxes with multiple boxing operations cannot be rewritten. M1: see E1. M2: at *, instead of an Integer, an Int is on the stack, but the escape method expects an Integer. We cannot just create a box at this point: if there are multiple escapes (or an escape is executed more than once), the difference could be observed (reference equality).

def e3(b: Boolean) = { val i: Integer = box(1) val j: Integer = box(2) escape(if (b) i else j) // * unbox(if (b) i else j) }

E4: M1 supports rewriting unbox operations of immutable boxes that escape def e4 = { val i: Integer = box(10) // 10 is stored into a new local, loaded as argument for the box call escape(i) // not changed, still loads the local i holding the box unbox(i) // rewritten to a pop (of the box) and a load of the local variable }

E4 seems to be a bit of a corner case, but it's necessary to unblock box eliminations with mutual dependencies. Example:

val ((a, b), c) = ((1, 2), 3) a + b + c

generates (after a few cleanups) the following (pseudo-bytecode, ignoring primitive boxing, specialization):

load 1, load 2, new Tuple2 // stack: Tuple2 load 3 // stack: Tuple2; Int val local1 = new Tuple2 val local2 = local1._1.asInstanceOf[Tuple2] val c = local1._2.asInstanceOf[Int] if (local2 == null) throw new MatchError(local1) val a = local2._1 val b = local2._2 a + b + c

In order to eliminate the tuples, we first need to eliminate the outer tuple (stored in local1)

• single box operation, so we use M1
• there are three consumers of the outer tuple: local1._1, local1._2 and new MatchError(local1). in the last one, the tuple escapes.
• note that the MatchError creation is dead code: local2 is never null. However, our nullness analysis cannot identify this: it does not track nullness through tuple stores and loads.
• if we re-write the non-escaping consumers of the outer tuple, but keep the tuple allocation and the escaping consumer, we get the following:

load 1, load 2 val newLocal1 = new Tuple2; load newLocal1 // stack: Tuple2 val newLocal2 = 3; load newLocal2 // stack: Tuple2; Int val local1 = new Tuple2 val local2 = newLocal1 val c = newLocal2 if (local2 == null) throw new MatchError(local1) val a = local2._1 val b = local2._2 a + b + c

At this point, the nullness analysis sees that local2 == null is false, dead code elimination removes the throw new MatchError(local1). After eliminating the allocation of the outer tuple, the inner tuple (stored in newLocal1) can also be eliminated.

Special case for tuples wrt specialization: a tuple getter may box or unbox the value stored in the tuple: calling _1 on a Tuple2$mcII$sp boxes the primitive Int stored in the tuple. Similarly, calling _1$mcI$sp on a non-specialized Tuple2 unboxes the Integer in the tuple. When eliminating such getters, we have to introduce appropriate box / unbox calls.

TODO: add new calls (box / unbox) to the call graph (not urgent) TODO: update the call graph because stack heights change (not urgent). this may also affect other optimizations, we ignored the issue so far. check how stack heights stored in the call graph are used. Note: these tasks are not urgent because the call graph is not currently used during / after method-local optimizations, only before to perform inlining and closure rewriting.