Idea how to implement VT/VO compatibility in JVM
stef at epardaud.fr
Thu Jan 22 08:24:56 UTC 2015
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.
More information about the valhalla-dev