Lifting operations from inline classes to reference projections

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Dec 16 14:14:38 UTC 2019


On 06/12/2019 19:56, Brian Goetz wrote:
> If we have an inline class:
>
>      inline class V {
>          public void m() { }
>      }
>
> then, at least for the public members of V (if not more), we would like to lift these onto the reference projection:
>
>      V.ref vr = …
>      vr.m()  // succeeds
>
> One way to get there is to simply have the compiler desugar these members onto the reference projection.  This is simple for the VM, in that these become ordinary interface calls and no additional VM help is needed, but on the other hand, we are now duplicating members between V and V.ref, which VM folks don’t like.  The VM folks would prefer that V.ref be an “empty” interface.

Is there a way to do this by appealing to delegation? E.g. rather than 
completely duplicating the V member in V.ref, can we use the cast trick 
below to add a "bridge" from V.ref to V?

I'm not too worried about having a V.ref with its own members - after 
all, V.ref should be a language fiction (for the VM, the only real thing 
is V). So, in my mental model, it will be javac, not the VM, to do most 
of the lifting here. Am I wrong in my assumption?

Maurizio

>
> Another would be to appeal to casting; desugar `vr.m()` as `((V) vr).m()` in the static compiler.  This works, until we want to make V private (and the combination of public reference projection and private implementation is expected to be a common one.)  If we do this, we’ll get a linkage error trying to resolve the cast, since it names a class not accessible to the client.
>
> A third way is to soften up the linkage requirements for `invokeinterface` when in the presence of a reference projection.  Here, when called upon to link an invocation, if the method is not present in the interface, and the interface is a reference projection for V, we can try to link to the corresponding method on V, _ignoring access control for V itself but still doing access control for the method_. (This also has the benefit of working for non-public members too.)
>
>
>
>


More information about the valhalla-spec-observers mailing list