Bridge methods in the VM
brian.goetz at oracle.com
Mon Jan 28 21:00:30 UTC 2019
> I'm worry that we are missing the big picture here, bridging by the VM
> is one way to patch the vtable, there is another feature we need which
> is also equivalent to paching the vtable, the where condition, the
> method specialization where a generic method is replaced by a specific
> version depending on the value of the type arguments.
We're not missing that picture; we're just separating the two issues.
But, bridging is _not_ just about patching the vtable. As outlined
here, it is about _redirecting_ before selection time.
Compiler-generated bridges can only operate at selection time;
forwarding bridges can also operate at resolution time, eliminating the
problem of "stale" bridging code (and enabling bridging for fields.)
> Note that if instead of a forwardeeType being a descriptor, we use a
> constant method handle, we have the semantics of the lambda
> metafactory when there is no captured values.
Right, but that only handles the part where you actually want to invoke
the bridge. It doesn't address the resolution-time option of not
calling that method _at all_, but instead calling a different method.
(Method handles already have their invocation mode built in.)
More information about the valhalla-spec-observers