RFR: JEP 359-Records: reflection code

[forax at univ-mlv.fr]

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

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

Having one bootstrap method makes the code more compact, because the boostrap method descriptor is shared inside the constant pool.
But, you still have several boostrap method infos inside the BootstrapMethods attributes because the arguments of each BSM call is different.
Having the same constant dynamic constant as argument for all bootstrap method calls allows more sharing.

If we want more sharing, we can also make a new kind of constant pool constant to store the record components.
It's not straightforward because a constant pool constant has to have a fixed size, so it can not store directly the record components but
a constant pool constant can reference an attribute (the Record attribute) just by it's name and no value.
With that, the bootstrap method calls will be able to load directly all the info needed to implement equals/hashCode and toString by reifying the record attribute into a RecordDescriptor. 

> 
> Maurizio

Rémi