Updated VM-bridges document

[forax at univ-mlv.fr]

> 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 20:39:03
> Objet: Re: Updated VM-bridges document

> 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.
It's an optimization, i prefer the VM to recognize a specific BSM and don't upcall it because its semantics is well known, it has the same effect but it's an implementation detail and not something that need to figure in the VM spec. 

> 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.

i agree, 
a peculiar BSM has to be able to do the migration in both ways from old to new and new to old. 

Rémi 

>> On Apr 8, 2019, at 1:18 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>>> De: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> 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