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

[Dan Heidinga]

>
> 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 mask in MethodTypeDesc, which would have to carry the bits around (and expose them) through combinators like dropArguments().  Seems possible, but also seems like there's gonna be some whack-a-mole handling the wash-off cases.

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

>
> Stepping back, the ClassDesc type was originally intended to model the C_Class constant pool entry.  And there's not L* flavor of C_Class.  But, it is also reasonable to use ClassDesc as a way of describing a field descriptor in a bytecode API (and similar for MethodTypeDesc.)
>
> Presumably the preload attribute is one attribute for the whole class.  That means that a classfile reader would have to parse that attribute, and when dispensing ClassDesc to clients, would have to look in the table to see whether the class is there?

That sounds right.  The classfile reader would need to expose whether
the classfile was treating a given descriptor as an L or L*.  It's
kind of annoying but if we don't apply the stars when reading the
classfile, we need to reify the preload attribute in some other way
which will lead to consistency problems.

Pulling on the reify the attribute thread a bit - jl.constant would
then grow a PreloadDesc class (yuck!) that a classfile reader could
fill in.  Existing apis that deal with ClassDesc would then also need
to know about the PreloadDesc and would need some way to pass it
through resolution-related APIs so it could eventually be written back
to a classfile.  To be clear, I'm thinking of apis like the of*()
methods on DynamicConstantDesc.  All in all, this feels way worse than
tracking the preload bit on the ClassDesc.

>
> Also, how would this affect ClassDesc::equals?  Would LFoo and L*Foo be equal?

I think they'd have to be equal as they represent the same descriptor.
It's only the presence of side channel info - the star - that makes
them different and the difference is only in the "go and look"
behaviour.  The VM will treat them as identical when dealing with
descriptor strings.

--Dan