Evolving the wrapper classes

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Jun 19 19:51:00 UTC 2020

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 19 Juin 2020 21:27:12
> Objet: Re: Evolving the wrapper classes

>> On Jun 19, 2020, at 12:54 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 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.
> In the VM this is mostly a verification problem: have a
> '[Qjava/lang/Integer$val;', need a '[I'? You're good! ("Mostly", because there
> is still the matter of ensuring there's a single encoding for both kinds of
> objects, or that the instructions are capable of handling two different
> encodings.)
> I'm not sure we'd get into any situations where a '([I)V' descriptor needs to
> override a '([Qjava/lang/Integer$val)V' descriptor, or vice versa, until we get
> to specialization,

covariant return type
  interface I {
     int foo();
  interface J {
     Object foo();
  class A implements I, J {
    int foo();

with I.java compiled a long time ago.

> and then I'm not sure this is any different than other forms
> of bridging. All existing code will continue to use 'I' in its compiled
> descriptors.

if everything is compiled at the same time, there is no issue, otherwise you can create a loop.


More information about the valhalla-spec-observers mailing list