Evolving CONSTANT_Class

[Dan Smith]

Some thoughts, working backwards from species, that may inform this decision.

A *species* is a specialization of a (generic) class or interface, where by "specialization" we mean the class/interface declaration interpreted in the context of a constant pool that has been modified by inserting certain resolved constants.

At the use site (think 'new'), we informally talk about a species like 'List[Val]'. What this means is "the species produced by resolving 'List', resolving 'Val', and modifying the constant pool of 'List' with the resolved 'Val'".

It will also be common to talk about species like 'List[T]', where 'T' is represented by a constant pool entry that will be filled in with a live constant.

This suggests that our representation of a species should combine 1) a pointer to a Class constant, and 2) pointers to other resolvable constants (typically, but maybe not exclusively, representing types).

I think we intuitively want to encode a species with something like 'Class("LList[QVal;];")', but this encoding is flawed:
- There's no constant pool entry to cache the resolution of List
- There's no constant pool entry to cache the resolution of Val
- There's no way to encode a live type argument (List[T]), so we'd need a separate encoding for that
- Depending on the domain of type arguments (can I use an integer?), there's no descriptor string encoding for many other type arguments; again, we'd need a separate encoding

I'm appealing here to a design principle that seems to have driven the original constant pool design: Class constants are for things that get resolved (and can be cached); descriptor strings are little more than fancy names. This principle doesn't always get followed: the verifier sometimes loads classes named by descriptors; array type class constants resolve their element types without a separate entry; more recently, StackMapTables use Class constants to represent types, and MethodTypes resolve method descriptors "as if" there were class constants for all of the parameter types. But I think these, especially the recent ones, are mistakes, and I still think the original notion is a useful separation of concerns that we should try to follow in our design.

Implications, if you buy this argument:

- There's got to be some sort of new CONSTANT_Species entry consisting of pointers to the generic class and the type arguments.

- For class-flavored references that allow species (super_class, interfaces, new, maybe this_class), either a Class can point to a Species, or a Species can appear as an alternative to a Class.

- For type-flavored references (Methodref, instanceof, anewarray), again we need either a Class/Type that can point to the Species, or we allow the Species as an alternative to be referenced directly. A distinct problem here is that we need a way to express whether the species type is an L type or a Q type. Maybe that's an extra layer, or maybe it's built into CONSTANT_Species. (This is really the same problem as what we do about L vs. Q class types, but without the legacy constraints.)

- For bare descriptors (type of a field), it's fine to use something like "LList[QVal;];". Or maybe it's useful to describe descriptors in terms of Class/Species constants. In any case, there's still a need to figure out how to parameterize a descriptor with live constants ("LList[$T];"), but I think this can be set aside as a separate problem.

-----

Bonus round: generic methods.

Generic methods work a lot like species—at the use site, we need to be able to refer to a method in the context of a constant pool that has been modified by inserting certain resolved constants. (We might even want to use the term "species" here, too. Or maybe it's "specialized method", where "specialized class" = "species".)

The existing representation of a method to be invoked is a Methodref, which has pointers to a Class constant, a name string, and a descriptor string.

So I think we need CONSTANT_SpecializedMethodref, which has 1) a pointer to a Methodref constant, and 2) pointers to some resolvable constants (typically, but maybe not exclusively, representing types). (Caveat: there are some details about the interaction between type arguments, overriding, and method resolution that I'm hand-waving about. Maybe the encoding will be stacked a little differently.)

Again, we can either somehow wrap the SpecializedMethodref in a Methodref (this seems a lot more awkward that it does when wrapping a Species in a Class), or we can allow the use sites (invoke instructions, mostly) to point to either Methodrefs or SpecializedMethodrefs.

-----

Where this leaves me (acknowledging that I've made some leaps that some people might be more skeptical of) is pretty down on options (1) and (2). If we do (4), CONSTANT_Type is going to be heavily overloaded: it can refer to a descriptor, a SpeciesType, an ArrayType (for arrays of species types), a type variable, etc. Basically, the distinction between (3) and (4) amounts to whether outside references can point to one of many alternatives, or whether they're all routed through a CONSTANT_Type, which then points to one of the alternatives. I can imagine good arguments for both of those alternatives.