I want to drill into this point a bit. I know that you would prefer not to make heroic efforts to deal with cases where a random subset of a hierarchy was compiled with one polarity and the rest with the other, but I think there’s reasons to keep drilling on it. (Also, because I don’t think you’ll get away with it.)
I’ll note that this reminds me further of a related migration discussion in Burlington (DanH was there too) when we were exploring how to crowbar L/D primitives into one slot. Teaching the interpreter to do so in a consistent world was easy; the hard part was dealing with calling sequences / overrides across separately compiled files that had differentially gotten the memo about the new encoding. We talked about various adapters/fixups needed at the junction of a slot arity mismatch. While we didn’t solve it then either, I claim we want to solve it anyway, because this is how we get to primitives as values. Just as the ValueTypes attribute lists the types known as of compile time to be values, we can similarly reify, on a per-class basis, whether the class is able to treat primitives as values. When class A calls / overrides a method in B with the same encoding, everything is great; when A and B differ on the value-ness of primitives, an adaptation, similar to the scalarize/bufferize adaptation, is needed at the junction. Over time, fewer classes will be out of date and the adapters will eventually be purged from the ecosystem. > On May 10, 2018, at 11:52 AM, Brian Goetz <brian.go...@oracle.com> wrote: > > I’ll add that this reminds me very much of loader constraints. When class C > calls method D.m(P)R, we first textually match the call with m(P)R in D via > descriptor match, and then we additionally make sure that C and D agree on > any loader constraints, throwing an error if they do not. In L-world, > whether C and D think V is a value or object class is another kind of > constraint. At linkage time, if these constraints agree, they can use an > optimized protocol; if they disagree, rather than failing, the VM can > introduce hidden adaptation to iron out the disagreement. This is a big win > over the use of bridges in Q-world, since the adaptors are only generated at > runtime when they are strictly needed, and as the ecosystem gets recompiled > over time to a more uniform view of V’s value-ness, will steadily go away. > We saw shades of this in Albert’s first prototype of heisenboxes, where the > JIT compiled multiple versions of each method (if needed) according to > different views of value-ness, and then fit them together, lego-style.
