JDK-8230501: Class data support for hidden classes
john.r.rose at oracle.com
Wed Nov 11 21:47:42 UTC 2020
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
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
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.
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.
$* 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
More information about the valhalla-dev