> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Tobi Ajila" <tobi_aj...@ca.ibm.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>, > "valhalla-spec-experts" <valhalla-spec-experts@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 > generics." > 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. Rémi > 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?
