Let's do an ASM thought experiment.
The descriptors live in (a) {method,field}_info metadata, and (b)
C_{Field,Method}Ref constants referred to by invoke/field access
instructions.
The stars, though, live somewhere completely different: the Preload
attribute, which is not on the instruction, or the code attribute, or
the method/field, but on the class.
I would expect ClassVisitor to be enhanced with something like
visitPreload(String clazz)
So, when reading a classfile, you get a bunch of preload "events", and
then eventually, when you get to method/field metadata, or instructions,
you get a bunch of events that have L descriptors in them, with no stars.
ASM commits to delivering certain events before others, so when
adapting, you might accumulate the visitPreload events into a List, and
then if you are inserting new instructions that are supposed to use L*,
if they're not in the list, you'd emit extra visitPreload calls.
(Presumably also ASM would want to filter the Preload values to
eliminate duplicates.)
Similarly, when writing a classfile, if you want to do a getstatic of a
field known to be an L* field, you might do something like:
b.visitPreload(internalName(C))
b.visitFieldInsn(GETSTATIC, receiverClass, "foo", eLdescriptor(C))
Which is to say, one of the costs of this scheme is that the stars go
far away from the descriptors they are attached to (not even in 1:1
correspondence), and classfile manglers will have to keep this mapping
somewhere.
My first instinct is that putting the stars in the ClassDesc is putting
the bookkeeping in the wrong place.
Let's look at other uses of ClassDesc; one was the constant folding
example. We want to be able to intrinsify LDC operations, including
condy, and indy calls. Do any of them need preloading to work
properly? (The *s are about preloading constraints.)
LDC'ing a C_Class will already force loading of the class (and besides,
C_Class has no use for a *.)
Invoking an indy which returns an L*Foo might want Foo preloaded. I
don't know enough about the timing of indy linkage to know whether all
the classes in the type descriptor are loaded by the time the calling
convention is set up, but I suspect it may already be?
On 12/16/2021 4:24 PM, Dan Heidinga wrote:
Which makes me ask ... if it really is a side channel, does it really go
*in* the ClassDesc?
If it's not in the ClassDesc, then how do we communicate the side
channel to users - e.g. class file generators?
I recently rewatched your JVMLS talk from 2018 [1] where javac
converted the jl.constant version of the descriptions into an `ldc`.
Now none of that is in the language yet but if we drop the stars from
descriptors now, the info won't be available when/if that vision comes
to fruition.
--Dan
[1]https://urldefense.com/v3/__https://www.youtube.com/watch?v=iSEjlLFCS3E&list=PLX8CzqL3ArzVnxC6PYxMlngEMv3W1pIkn&index=2&t=2s__;!!ACWV5N9M2RV99hQ!cSDE-Mpt9NsrFZwwEnoJ2sUm92OQqIlb9bDfBvr96zxWf-9NjmWc3mGzBCLje9p5EQ$
