JDK-8230501: Class data support for hidden classes

[John Rose]

On Nov 10, 2020, at 1:35 PM, forax at univ-mlv.fr wrote:
> 
>> De: "mandy chung" <mandy.chung at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoyé: Mardi 10 Novembre 2020 22:17:04
>> Objet: Re: JDK-8230501: Class data support for hidden classes
> 
>> Hi Remi,
> 
>> This is not intended only for the vector API implementation but rather for
>> clients who define hidden classes with more than one live objects as class
>> data. Otherwise each client will have to write a similar convenience method
>> which also needs to handle the unboxing conversion if the constant is a
>> primitive type.
> 
>> I see the downside for this convenience method is only for List (recommending to
>> use immutable list) which can be extended when we have frozen array.
> 
>> Any other issues you see for this convenience method?
> I think it's better to use a structured object like a record instead of using a list which requires all objects to have the same type. 

Using a record here would be cute, but overkill.  The resulting
constant pool would be burdened by the need to fully name
each record accessor (unless you made a convention for by-name
access, somehow, but we might as well do by-index at that point).

Each record accessor requires a C_NameAndType, a C_Methodref,
and a C_MethodHandle, plus 2 C_Utf8’s to represent the field
name and descriptor.  By contrast, each by-index access point
needs a distinct C_Integer and a bootstrap specifier to refer to it,
or (alternatively) a distinct C_Utf8 and C_NameAndType, if the
index is encoded in the name argument of a common BSM.
It’s not even close:  The by-index accessor puts much less
pressure on the constant pool than the by-record-element
accessor.  And that’s what counts, when designing condy
BSMs.

The constant pool is *not* a place where type-ful programming
is a great benefit.  Assuming that the code generator isn’t broken,
we can trust that the various (probably heterogenous) elements
of a ClassData list will be correctly typed for their individual
uses.

Finally, note that Mandy’s (and my) index-based convention
here *is type-ful where it counts*:  The type argument to the
BSM (which also requires a C_Utf8 and the same
C_NameAndType as used by the name) provides the same
full static type information as the “cute” record accessor.
So, even though the ClassData is a List.of, apparently
untyped, each indexed element is pulled out of the list
with a full static type (enforced by a cast, of course).

Remi, I don’t think you’ve made a case for omitting
classDataAt, after all, and certainly not a case for a
competing record-like classDataAt.  Mandy is right
that every client is going to have to design an
alternative, so let’s just do it right in common code.

— John

P.S. One idea for cutting two functions down to one:
Encode the selection process into the (otherwise useless)
name argument of the C_NameAndType in the condy.

NAME   VALUE
$*      the ClassData object itself
$0      element 0 of the ClassData
$1      element 1 of the ClassData (and so on $2, …)
(other)  reserved for future use