RFR: JEP 359-Records: reflection code

[Maurizio Cimadamore]

On 22/10/2019 09:43, forax at univ-mlv.fr wrote:
> ----- 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.

Let me rephrase. We have Class::getRecordComponents; and we have 
RecordComponent::accessor.

What is the need to pass _anything_ to the BSM, other than the record 
class (e.g. Point.class) AND the method name (e.g. toString) ?

The BSM can take the .class, and get the components; from there:

- you can easily derive names
- you can also easily derive accessor MHs (just a lookup away)

I was _not_ advocating for extracting a name from a direct method handle 
- that seems brittle, given that the compiler implementation might 
change, eventually. But doubling down on the reflection API seems the 
right thing to do?

Maurizio

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