CONSTANT_Dynamic bootstrap signature restriction

[Brian Goetz]

I'm fine putting in Dan's restriction and buying the option to do it or 
not.  But, if we don't put in the restriction, then we can never do it.  
Not fine with that.

> My point is that you can do that for Condy but not for Indy because Indy is already specified in term of invokeWithArguments.
> And i think everybody in the EG that has to maintain a VM implementation will agree with me that it's better to have Indy and Condy semantics to be aligned.

I don't actually agree to that.  Sure, all things being equal, 
gratuitous misalignment is unfortunate.  But, we've learned a lot since 
indy, and I think that Condy will be used 100x more than indy, and (at 
least in static languages like Java), the vast majority of indy (any 
that return CCS) will become condy.  So given the choice between "follow 
in the footsteps of indy's limitation", and "make condy even better", I 
choose for the latter, and the inconsistency is a small price to pay.

Further argument: I think metadata-less condy will be very frequent.  
But of the indy's that can't become condy (those with mutable call 
sites), I think few of them can be metadata-less.  So the asymmetry 
makes condy much better and doesn't make indy much worse.

On 3/7/2018 5:39 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "daniel smith" <daniel.smith at oracle.com>, "Daniel Heidinga" <Daniel_Heidinga at ca.ibm.com>, "valhalla-spec-experts"
>> <valhalla-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 7 Mars 2018 19:28:00
>> Objet: Re: CONSTANT_Dynamic bootstrap signature restriction
>>> Daniel (S), Brian,
>>> i think your view on this subject is biased by the fact that you built that
>>> library.
>> I can understand why you'd think that, but allow me to correct.  My view
>> is biased by the fact that I built the _first_ such library, and it was
>> pretty annoying, and I want to save future programmers from this
>> unnecessary annoyance.  And that we're working on language support that
>> virtually guarantees that others will want to write similar Java
>> libraries.  If this were just about compilers emitting bytecode, I
>> wouldn't care.
> Sure, javac support will help to have new users for condy but given the number people that have reviewed this API, it doesn't seem too popular,
> btw doing a proper review is on my todo list.
>
> Anyway, if you want to get ride of the first 3 parameters, you can trampoline, i.e having only one BSM that takes as first constant argument a method handle that construct the constants with fewer arguments and just call it. It's what i've done for the first version of cplisp [1]. Obviously it's not great in term of security so you also need to check that the given method handle had really been constructed from the lookup using lookup.revealDirect.
>
>>> And i will re-use the argument than Brian use rightly about java.lang.invoke,
>>> not a lot of people will write BSMs, so modifying an already complex API call
>>> (callsite info * lazy loading of constants * conversion of bsm arguments *
>>> varargs) to take care of hiding potentially unused arguments only for few users
>>> does not worth the added complexity.
>> I am saying that I imagine a future where the number of people writing
>> BSMs for condy is at least 100x bigger than it has been historically.
>> Again, if I thought this was just about me and you and Charlie, I
>> wouldn't care.  But I don't think that's the case here.
> I can imagine a lot of things, but we can also wait and see if the API becomes popular now that we are in a 6 month cadence.
>
> Rémi
>
> [1] https://github.com/forax/cplisp