Updated VM-bridges document

[Brian Goetz]

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, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190408/3df4cff5/attachment-0001.html>