Idea how to implement VT/VO compatibility in JVM

[Brian Goetz]

The projects are inter-related for sure (we probably wouldn't even be 
doing specialization without value types), but for now, our head is 
mostly on the generics side of the story.

I don't think splitting the lists would be helpful, though.  (The same 
people would be on both; many people would post in the wrong place; even 
threads that started out in the right place would eventually end up in 
the wrong place as the focus of discussion meandered as is typical for 
such discussions.)

I think the real problem is that we're at a stage where there's less 
people can do to actually contribute than they'd like (which you can 
think of as a good thing), and so that contribution-energy gets 
channeled into directions that may be well-intentioned but ultimately 
are counterproductive.

Probably soon, we'll be setting up a limited-write -experts list, at 
which point this -dev list will revert to its intended role, which is 
discussions pertaining to the implementation.  We can also do, as we did 
for lambda, set up a publicly writable -observers list for broader 
participation.


On 1/9/2015 2:55 PM, Palo Marton wrote:
> 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
> <mailto: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
>         <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>
>         <mailto: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...
>
>
>