This reminds me of an earlier version of the jl.constant API, where we
tried to track the varargs bit. In the end, we dropped this, because it
washed off too easily in the API. We could have a preload() bit that
travels with the ClassDesc, which would then have to be propagated into
a bit mas
>
> This reminds me of an earlier version of the jl.constant API, where we tried
> to track the varargs bit. In the end, we dropped this, because it washed off
> too easily in the API. We could have a preload() bit that travels with the
> ClassDesc, which would then have to be propagated into
If the preload() bit is tied to the ClassDesc, do we need to worry
about a bit mask in MethodTypeDesc? Isn't the MethodTypeDesc composed
of ClassDesc returnType and ClassDesc[] of parameters? I feel like
I'm missing some complexity here...
That's how the implementation happens to work, but
> 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.constan
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,
> 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 ins
