Idea how to implement VT/VO compatibility in JVM

[Palo Marton]

Seems that there is some confusion here. I was not addressing generics and
their specialization, but other problem. It is described in the first post
of this thread:

http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-January/000710.html

On Fri, Jan 9, 2015 at 8:12 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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...
>
>