RFR: JEP 359-Records: reflection code

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Vicente Romero" <vicente.romero at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Mardi 22 Octobre 2019 09:57:23
> Objet: Re: RFR: JEP 359-Records: reflection code

> Ok, so the goal is share of CP entries (should be documented somewhere).
> 
> I think in that case I would at least advocate for replacing the
> compiler generated string of names with some runtime concatenation using
> getter names; the concatenation is done at runtime, after all.

Getting the name from a method handle is not that simple.
Usually you can't. In this peculiar example you can because you can call revealDirect [1] on the lookup because the same lookup is used to create the getters and calling the BSM.

But i still think it's better to do not send any arguments and use getRecordComponents() at runtime or to enable object sharing between the BSM calls to use one constant dynamic as argument and initialize it with the calls to getRecordComponents().

[...] 

> Maurizio

Rémi

[1] https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#revealDirect(java.lang.invoke.MethodHandle)


> 
> 
> On 22/10/2019 03:40, Vicente Romero wrote:
>>
>>
>> On 10/21/19 6:32 PM, Maurizio Cimadamore wrote:
>>>
>>> On 21/10/2019 23:02, Remi Forax wrote:
>>>> - the same call works for equals/hashCode and toString, so depending
>>>> on the methods some arguments are not used or not
>>>
>>> I too found this a bit odd when looking at the javac code - it took
>>> me sometime to figure out what was going on.
>>>
>>> The question I have here is - is the decision of having a single
>>> point a deliberate decision that we think it's going to pay off in
>>> the long run?
>>
>> it was a deliberate decision, the first implementation actually had
>> different bootstrap methods but then we got a table with three
>> bootstrap methods per every humble record, so having only one
>> bootstrap method is a space gain.
>>> Or was it more a way to quickly bootstrap the javac implementation?
>>> If the latter, we should probably revert to one bootstrap per Object
>>> method.
>>>
>>> Maurizio
>>>
> > Vicente