Value types - compatibility with existing “value objects”

[Brian Goetz]

> Why is # of registers a factor here? I'd expect some # of registers to
> be used for passing some of the values (depending on calling
> convention), and the rest passed on the stack.
>
> This is also the first I hear of VM reserving the right to transparently
> box depending on some size threshold.  My preference would be to simply
> use the stack, and if you run out of stack, handle that the same way as
> today.  Clearly someone passing a giant value type around is not doing
> themselves any good, but the automagic boxing behind the scenes doesn't
> sit well.  What if boxing that giant value type causes an OOM? I don't
> think that would be expected.

That would be taking away a valuable degree of freedom for the VM to 
optimize.

Suppose you have a big value type VVV with 1000 fields, a1 .. a1000. 
Now you have:

class Foo {
    VVV biggie;
}

and a method:

void getA33(VVV biggie) { return biggie.a33; }

and a call

getA33(foo.biggie);

Do you want to push 1000 elements on the stack just to pick #33?  The 
"value" is already on the heap, in the "biggie" field of Foo.  Why not 
let the VM pass it by reference, saying "that's the big value you want, 
over there", and let the VM make the tradeoff based on the relative cost 
of copying N elements to the stack vs the indirection to the heap?

The bytecodes define the semantics; the VM should be free to pass via 
registers or stack or heap or smoke signals based on what it decides is 
the best.

The size of register files and stack segments will likely be one input 
into these calculations.



Another consideration is atomicity, for values that need to be 
guaranteed tear-free.  If they fit into a cache line, there's probably 
already a free atomic update mechanism available to the VM; if the value 
is big, the VM might prefer to box the value and CAS on the reference. 
(Or maybe there's hardware TM available.)  We let the VM make these 
choices.