JDK-8230501: Class data support for hidden classes

[forax at univ-mlv.fr]

> 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 ]
> wrote:

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

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 
LDC condy 
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

Rémi 

> 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