Idea how to implement VT/VO compatibility in JVM

[Brian Goetz]

> For object field it should work this way:
>
> Descriptor of such field will be "VT erased" to boxed class and metadata
> will indicate that the field was actually declared as VT. When JVM loads
> such class, it checks the metadata and lays out the class according to
> that. The field will be flattened inside the object. This will also
> change semantic of "getfield" and "putfield" instructions for such
> field. In interpreter getfield will read flattened data and box it on
> heap, putfield will write flattened data into the object. In JITed code
> it will do the best think possible.

Sure, that's the easy part (and even that is not totally easy.)

The hard part is: the entire VM field-access model is built around 
translating field accesses like

   getfield Foo.x [ receiver ]

to native code that looks like:

   (ideally elided) verify receiver is a Foo
   result = *(receiver + sizeof(HEADER) + offsetof(x))

based on the assumption that all instances of Foo have Foo's fields at 
the same offsets.  (For methods we achieve polymorphism with vtables; 
for fields, we achieve it by adding subtype fields to the end of base 
type fields.)

But, if I have a class Box<any T> with a single T-valued field, I need 
different layouts; one for erased refs, one for ints, a longer one for 
longs, etc.  (And of course this perturbs the offset of other fields.)

Code that is generic in T that wants to access Box<T>.t now has to deal 
with different layouts; this is a pretty big change to our compilation 
story (with consequences for performance.)

So, I think we're back at "just completely rearchitect the JVM, and it 
is all easy" :(

Of course, we are willing to consider changes in the VM architecture. 
But we also have to be realistic...