Idea how to implement VT/VO compatibility in JVM

[Stéphane Épardaud]

On 01/21/2015 07:39 PM, Maurizio Cimadamore wrote:
> Thanks, there are some useful thoughts in here, we're still thinking 
> about directions.
>
> To some extent, this whole specialization business is like a knob - on 
> one end of it there's a 'performance' label, on the opposite end 
> there's a 'language uniformity' label. I think it's fair to point out 
> (as you and others have done) that the current proposal has the knob 
> turned all the way up to the performance end (which was kinda the 
> point!) and that if, somehow the knob was turned back a little, a 
> slightly different compromise could be achieved. Does different means 
> better? Jury's still out :-)

I don't think my proposal affects performance _at all_ compared to the 
current implementation. It does allow for auto-boxing due to equivalence 
of boxed/unboxed value types, which is more flexible since it allows a 
uniform view of "everything's an object" (at the cost of boxing) but at 
the same time the current performance of specialisation for unboxed 
value types exactly as the current implementation allows.

What it does limit though is what sort of generics can be used in the 
type of public fields. That's more a knob of language feature, where the 
current implementation does not limit this but limits what we can do 
with value type generics, whereas my proposal makes this more regular 
but with the limitation of what you can declare as public fields in such 
an any-generic type.

Note that what I'm really looking for here is a whole in my proposal. I 
haven't found one yet (except for the limitation on public fields) but 
that's probably because I'm not as used to the problem as you guys are. 
If there's really no hole and it's really a plausible implementation I'm 
willing to help test it, possibly by implementing it. I've some 
knowledge of the internals of javac and the bytecode, thought nothing on 
the VM front I'm afraid.