Inline Record

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Srikanth"
> <srikanth.adayapalam at oracle.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Jeudi 7 Mai 2020 01:11:35
> Objet: Re: Inline Record

> On May 6, 2020, at 3:42 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> Eventually, inline classes will inherit eq/hashCode from Object.

> Crazy half-baked idea of the moment:

> Factor the equals/hashCode/toString methods for records into
> static methods (in ju.Objects) which are configurable appropriately,
> and have a default configuration. Use ClassValue for performance.

> Then define equals/hashCode/toString in jl.Object (yes, Object)
> to call those methods, *when the receiver is a Record and/or an inline*.

> Two ideas here: 1. No per-class indy or BSM at all, but a ClassValue
> instead. (We should do this for Record anyway.) 2. Push the specification
> all the way up to Object. (2 makes more sense for inlines than for
> Record, since it’s natural to define equals/hashCode/toString in
> the class hierarchy, if there’s a place to put it. There isn’t for inlines.)

Conceptually a ClassValue is like a vtable, so you want the JIT to build a kind of inlining cache (apart if the class is a constant) to avoid to hit the ClassValue if a callsite is monomorphic. 
Building this kind of inline cache is far easier with an indy. 
So if you want a method equals/hashCode and toString inside java.lang.Record, we need "classy", another mechanism that using a BSM but that time when a vtable slot is derived, when a record ask for the equals/hashCode/toString of java.lang.Record. 

It's also not dissimilar to the Bridge-o-matic of Brian, the Forward attribute, equals/hashCode and toString being bridge declaration in j.l.Record and the VM creating the equivalent of an indy calls when building the vtable. 

> — John

Rémi