value type hygiene

[forax at univ-mlv.fr]

Hi John, 
it's an implementation details, right ! 

The strawman strategy is to always consider that you have to send a pointer, so you need to buffer value types before calling a virtual method, if it's not a virtual method you can do the adaptation because you know the caller and the callee. All other strategies should be semantically equivalent. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 10 Mai 2018 21:06:28
> Objet: Re: value type hygiene

> On May 10, 2018, at 11:53 AM, John Rose < [ mailto:john.r.rose at oracle.com |
> john.r.rose at oracle.com ] > wrote:

>> The easiest thing is to assign *one* calling sequence per v-table
>> slot, based on the preferences of the first class allocating the slot.

> P.S. I suppose that key point was too telegraphic.

> Trying again:

> The easiest thing is to recognize that we can (and do, already)
> assign *one* v-table slot and highest super-class to each concrete
> method defined in a class. (Default methods don't get to do this,
> though.) If the method is not an override (according to descriptor
> match, not JLS rules), then that class is the super and the v-table
> slot is fresh. If the method is an override, then it inherits its v-table
> slot from the method it is overriding.

> Given that assignment, we can assign a unique calling sequence
> per v-table slot, and (equivalently) to the tree of overrides in that
> slat. Base this on the preferences of the highest class (common
> super). All concrete methods sharing that same v-table slot
> must interoperate with the same view of types. The CLCs
> dictate the same thing, already. The CLC mechanism may
> be extended (if we choose) to spread the unique calling sequence
> constraint through default methods. This would enforce a
> unique view of val vs. ref across all v-table slots, for each
> concrete method, even defaults.

> The above logic works even if your JVM impl. doesn't use
> v-tables. The rules simple decorate methods according to
> the preferences of the highest classes in in each override
> tree.

> Can the "highest class" define its method as abstract,
> not-concrete? Sure; then you have an override forest,
> not an override tree. So you assign the same calling
> sequence to the whole forest. And the information is
> rooted in the abstract method. That's why I started out
> by saying the information flows from a v-table slot.
> But it flows through concrete overrides, as well as
> (optionally) the top method that they all override.