JDK-8230501: Class data support for hidden classes
forax at univ-mlv.fr
forax at univ-mlv.fr
Wed Nov 11 22:41:50 UTC 2020
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "mandy chung" <mandy.chung at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 11 Novembre 2020 22:47:42
> Objet: Re: JDK-8230501: Class data support for hidden classes
> On Nov 10, 2020, at 1:35 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>>> De: "mandy chung" < [ mailto:mandy.chung at oracle.com | mandy.chung at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-dev" < [ mailto:valhalla-dev at openjdk.java.net |
>>> 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
I suppose i'e to explain to you diabolic plan to rules the world :)
You want to use a condy per value inside the class data, i don't,
i want one condy to rule them all, because the record fields are trusted final fields, so in term of bytecode,
i propose to generate
invokevirtual MyRecord accessor()
The JIT will convert it to the right constant easily.
> 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.
Is it better now ?
> — 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
More information about the valhalla-dev