OK, I see what you’re getting at now. Yes, this is one of the implementation possibilities. I was mostly looking to validate the concepts before diving into the representational details. One key point is that the default case should be able to proceed with no bootstrap; a small set of adaptations handles the most important cases, and avoiding an upcall is probably pretty desirable if we can get away with it.
But, given that, an index to a BSM entry is probably fine; it moves the representation of “which arguments are adapted how” into a static argument list, which is probably the best place for it. One non-obvious point here is that the adaptation must work _in both directions_. If we are migrating Collection::size from returning int to returning long, not only do we want to widen the result implicitly when invoked by legacy callers, but we have to _narrow_ the result when overridden by legacy subclasses. > On Apr 8, 2019, at 1:18 PM, fo...@univ-mlv.fr wrote: > > > > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Lundi 8 Avril 2019 16:24:21 > Objet: Re: Updated VM-bridges document > > The other thing is that Forwarding bridge should not use an adapter but a > bootstrap method. > > Can you explain exactly what you mean here? Because in my mind, the adapter > _is_ a bootstrap method — it is code to which the VM upcalls at preparation / > link time to help establish linkage. > > Since you obviously have a more specific notion of “bootstrap method”, can > you explain exactly what you mean? > > it's a kind of bootstrap method but with not with the same ceremony as the > one used by indy or condy, i.e. no lookup and no constant bootstrap arguments > (and no name and no descriptor), > i propose to the same protocol as with indy or condy. > > Rémi >
