value type hygiene

[John Rose]

On May 10, 2018, at 11:53 AM, John Rose <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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180510/25c480b4/attachment.html>