[External] : Re: Enhancing java.lang.constant for Valhalla

[Brian Goetz]

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