with the library • does not have all specializations • slow when used by miniboxed code • fast calling from miniboxed code • all specializations are there MbFunctionX
with the library • does not have all specializations • slow when used by miniboxed code • fast calling from miniboxed code • all specializations are there MbFunctionX incompatible → coercions
concept repr. 1 … repr. n repr. 2 Constraints from the interaction with other language features: • generics • subtyping • virtual dispatch • DSL semantics (staging)
concept repr. 1 … repr. n repr. 2 Constraints from the interaction with other language features: • generics • subtyping • virtual dispatch • DSL semantics (staging) incompatible → coercions
List[Int](1, 2, 3).head val y: List[Int] = List[Int](x) val x: int = List[Int](1, 2, 3).head val y: List[Int] = List[Int](x) naive unboxing representation mismatch: expected: int (unboxed) found: Int (boxed)
List[Int](1, 2, 3).head val y: List[Int] = List[Int](x) val x: int = List[Int](1, 2, 3).head val y: List[Int] = List[Int](x) naive unboxing representation mismatch: expected: int (unboxed) found: Int (boxed) representation mismatch: expected: Int (boxed) found: int (unboxed)
– exposes inconsistencies in the representation • based on backward type propagation • from local type inference – so we introduce coercions • optimally, only when representations don't match
we'll be writing annotations written before types (e.g. “@unboxed Int”), although in the Scala syntax they are written after the type (e.g.“Int @unboxed”). This makes it easier to read the types aloud.
t2: @unboxed Int): @unboxed Int = if (Random.nextBoolean()) t1 else t2 inject coerce commit configurable introduction of annotations based on external constraints
t2: @unboxed Int): @unboxed Int = if (Random.nextBoolean()) t1 else t2 inject coerce commit : @unboxed Int expected type (part of local type inference) the return type of choice is @unboxed Int
t2: @unboxed Int): @unboxed Int = if (Random.nextBoolean()) t1 else t2 inject coerce commit : @unboxed Int matches: expected: @unboxed Int found: @unboxed Int
t2: @unboxed Int): @unboxed Int = if (Random.nextBoolean()) t1 else t2 inject coerce commit Replace: @unboxed Int → int (not showing Int → j.l.Integer)
similar transformation – less flexible (no annotations) – entangled with other transformations • we took what's good – and allowed the transformation to work on other use cases as well
explicit in types – representation mismatches • become type mismatches • are exposed by the type system – mismatches lead to coercions • explicit bridges between representations • are introduced automatically – regardless of the representations • at a meta-level
selectively picking the values to be transformed – value classes • cannot unbox multi-param values in return position (not supported by the JVM platform) • bridge methods – staging • annotations signal domain-specific knowledge – can occur inside generics (List[@staged Int])
• compile-time transformation – compatible with separate compilation – compatible with partial transformation – global scope (Graal/Truffle: local scope) • optimizes all data in a program
• compile-time transformation – compatible with separate compilation – compatible with partial transformation – global scope (Graal/Truffle: local scope) • optimizes all data in a program / containers – conservative (Graal/Truffle: speculative)
• compile-time transformation – compatible with separate compilation – compatible with partial transformation – global scope (Graal/Truffle: local scope) • optimizes all data in a program / containers – conservative (Graal/Truffle: speculative) Complementary optimizations
a high-level concept – into multiple representations – in a consistent way (through coercions) – in a selective way (through annotations) – in an optimal way (coerce only if necessary)
used in • the miniboxing plugin – for specialization – for function representation • other prototypes – value classes – staging Don't take my word for it
used in • the miniboxing plugin – for specialization – for function representation • other prototypes – value classes – staging Don't take my word for it Sources on github, artifact online.
the initial prototype, as a semester project • Eugene Burmako - the value class plugin based on the LDL transformation • Aymeric Genet - developing collection-like benchmarks for the miniboxing plugin • Martin Odersky, for his patient guidance • Eugene Burmako, for trusting the idea enough to develop the value-plugin based on the LDL transformation • Iulian Dragos, for his work on specialization and many explanations • Miguel Garcia, for his original insights that spawned the miniboxing idea • Michel Schinz, for his wonderful comments and enlightening ACC course • Andrew Myers and Roland Ducournau for the discussions we had and the feedback provided • Heather Miller for the eye-opening discussions we had • Vojin Jovanovic, Sandro Stucki, Manohar Jonalagedda and the whole LAMP laboratory in EPFL for the extraordinary atmosphere • Adriaan Moors, for the miniboxing name which stuck :)) • Thierry Coppey, Vera Salvisberg and George Nithin, who patiently listened to many presentations and provided valuable feedback • Grzegorz Kossakowski, for the many brainstorming sessions on specialization • Erik Osheim, Tom Switzer and Rex Kerr for their guidance on the Scala community side • OOPSLA paper and artifact reviewers, who reshaped the paper with their feedback • Sandro, Vojin, Nada, Heather, Manohar - reviews and discussions on the LDL paper • Hubert Plociniczak for the type notation in the LDL paper • Denys Shabalin, Dmitry Petrashko for their patient reviews of the LDL paper Special thanks to the Scala Community for their support! (@StuHood, @vpatryshev and everyone else!)