Evolving the wrapper classes
forax at univ-mlv.fr
Fri Jun 19 18:54:15 UTC 2020
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Tobi Ajila" <Tobi_Ajila at ca.ibm.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts-bounces at openjdk.java.net>,
> "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 19 Juin 2020 20:18:09
> Objet: Re: Evolving the wrapper classes
> Zooming out, what we've been trying to do is shake out the places where the JVM
> treats primitives and references differently, and aligning them, so that we are
> able to broaden the approach of "generics erase T to Object" to include inlines
> and primitives. The war cry might be:
> Object is the new Any
> L-World does much of this for inlines, but we don't want to leave primitives out
> in in the cold in the programming model; being able to get good behavior for
> Foo<Point> but not the same for Foo<int> would be a missed opportunity to
> provide a uniform programming model. Much of this is either handled by existing
> L-World behavior (e.g., behavior of ==), but this seam is one that needs to be
> covered. We can cover some in the static compiler (conversions between I and
> Qint) but when it comes to arrays, the invariance of arrays would expose our
> tricks, and we'd have to have awful restrictions like "you can't use arrays in
> Note that [I and [QInteger$val have the exact same layout, so it is really a
> matter of treating the two type names as referring to the same underlying
> runtime type.
yes, but at the same time descriptor are matched by name and you need to have the proper descriptor when overriding/implementing a method,
so the strategy of blindly replacing every I by QInteger$val; doesn't really work.
Usually the solution is to use bridges but bridges only work with subtyping relationship not equivalence relationship (because you can travel in both direction).
I believe we need to bring the forward/bridge-o-matic at the same time we retrofit primitive to inline.
> On 6/19/2020 1:07 PM, Tobi Ajila wrote:
>>> Because arrays have identity (not to mention potentially large copying costs),
>>> there is simply no reasonable conversion we can define; any "conversion" would
>>> involve copying all the data, changing identity, or both. Just as with the
>>> array subtyping requirements (Point <: Point.ref <: Object), these are
>> > things only the VM can do for us.
>> I suspected that this was likely due to the large cost of converting between
>> `[I` and `[java/lang/Integer$val`. However, I am still a little unclear as to
>> what the motivation is for this. Is this solely for specialized generics?
>> In Dan's examples with `I` and `java/lang/Integer$val`, the only places where
>> conversions are needed are when primitives are used as type parameters or to
>> call instance methods on them, both of which can already be done with primitive
>> arrays. So in the LW3 - LW20 timeframe would we have any need for these
>> conversions? If so, could you provide some examples?
>> In the case of specialized generics, is the intention that `[I` (and I suppose
>> `I` as well) will appear in generic code?
More information about the valhalla-spec-observers