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.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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.r...@oracle.com | > john.r.r...@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.
