Aggressive unboxing of values: status update

[Albert Noll]

Hi all,

I've been working on aggressive unboxing of values over the past couple 
of weeks. The project is in a very early state. The current prototype is 
designed around two principles: (1) implement unboxing as described 
below, (2) keep the required changes reasonably small. As a result, 
there is lots of potential for optimization. These optimizations can be 
added in later stages of the project. Aggressive unboxing aims at 
providing an efficient way to:

(1) pass values as parameters to functions
(2) return values from functions
(3) load and store flattened data in the heap
(4) provide insight into the implementation of value types

Let's consider this simple example:

value Complex {
   int x, int y;
   private Complex(int x, int y) {
     this.x = x;
     this.y = y;
   }
   public static Complex make(int x, int y) {
     return new Complex(int x, int y);
   }
}

class Test {
   void non_inlined_callee(Complex c) {
     int sum = c.x + c.y;
     System.out.println(sum);
   }
   void caller() {
     Complex c = Complex.make(1, 2);
     non_inlined_callee(c);
   }
}

Let's assume that Complex.make() and the constructor in Complex.make() 
is inlined into caller(). The compiler decides to not inline 
non_inlined_callee(). The current prototype recognizes that 'Complex' is 
a value and uses the unboxed components (x and y) to pass them to 
non_inlined_callee. I.e., the JIT compiler transforms the original call 
'non_inlined_callee(Complex c)' to 'non_inlined_callee(Complex c, int x, 
int y)'. Why to we keep the parameter 'Complex c'? The reason is that we 
want to keep - for now - the interpreter unmodified. I.e., by keeping 
'Complex c' in the signature, non_inlined_callee() can call native 
methods, the interpreter, or a C1 compiled method.

This is not optimal, but keeps things simple for now. In a later stage 
of the project, we plan to implement a 'boxing operation'. Boxing an 
unboxed value would be done only on demand. One thing that we need to 
think about is how we deal OOMEs when implementing 'lazy boxing'.
If non_inlined_callee() is compiled with C2, the compiled code expects 
the unboxed parameters and uses the unboxed arguments instead of the 
original reference to 'Complex c'. One benefit of using the unboxed 
parameters instead of the original object is that the JIT needs to be 
less conservative and therefore the compiled code quality is potentially 
better.
Providing this functionality (to prototype is not yet stable) requires 
changing ~2k lines in Hotspot. Many of the affected changes are in 
'critical' places. That's why I want to make sure that the prototype is 
reasonably stable before pushing. Current support for unboxing is 
implemented only in C2. The interpreter and C1 can remain unchanged for 
now. I have a bachelor student who is looking into a corresponding C1 
implementation.

Development Plan:
- Finish passing values as unboxed parameters for static methods
- Return values in registers for static methods
- Implement boxing operation
- Pass 'this' unboxed
- Make function calls without passing the allocated value object

Best,
Albert