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$

Reply via email to