Idea how to implement VT/VO compatibility in JVM

[Palo Marton]

May be to avoid such confusion it will be better to split project valhalla
(or just the mailing list) into separate parts:

- value types
- generic specialization (+enhanced volatiles)

Seems that your current focus is on generic specialization. Or are you
working in the same time also on value types?



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

> You may be right; I may have thought I was responding to a different
> "redesign the VM" suggestion (the fact that we get so many that they can't
> be kept straight, is already a sign of something else gone badly wrong.)
>
>
>
> On 1/9/2015 2:29 PM, Palo Marton wrote:
>
>> 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
>> <mailto: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...
>>
>>
>>