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, fo...@univ-mlv.fr wrote:
----- Mail original -----
De: "Brian Goetz" <brian.go...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>
Cc: "daniel smith" <daniel.sm...@oracle.com>, "Daniel Heidinga"
<daniel_heidi...@ca.ibm.com>, "valhalla-spec-experts"
<valhalla-spec-experts@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
