DRAFT DRAFT DRAFT

Currently a loaded constant pool is organized as a small bundle of arrays:

- a ConstantPool, an array of intptr_t (32/64 bits each)
- a u1(byte) array _tags (which can have internal as well as external values)
- a ConstantPoolCache (128/256 bits each) to track linked field and method references
- a u2 (16-bit)array _operands, recording bootstrap method data
- a pointer array _resolved_klasses tracking class references

(To this we may add additional arrays for tracking constants which may differ among different specializations of parameterized generics, such as the offsets of variant fields in species.)

Perhaps the design could be simplified at this point, by centralizing certain crucial non-pointer data in the main constant pool array, and moving all pointer data and expanded linkage tracking into associated side arrays. This process has already begun, and perhaps it would be profitable to continue.

Here is a straw man design:

- The main constant pool array is no longer an array of machine words, but an array of non-pointer entries of exactly 64 bits each. (Size neutral on LP64.)

- Each 64-bit entry contains the basic information needed to start processing the associated constant information, including its static information (derived from the class file) and its resolution state.

- The 64 bits are arranged in bit-fields of length 8, 24, 16, and 16. The 8 and 16 bit fields (both of them) contain the original corresponding class file bits, or associated values used to manage state transitions. (For primitive constants, either the two 16 bit fields are combined into a 32 bit constant, or the following 64-bit CP entry holds a 64-bit constant.) For non-primitive constants, the 24-bit value is an unsigned index into an appropriate table. Which table? That depends on the tag.

For class constants, the table is the resolved_classes array. Perhaps there is also a symbol array holding the unresolved names, or perhaps it is cleverly derived from some other source.

For string constants (and other oops, such as condy), the table is the resolved_references array.

For method and field references, the 24-bit index points into the CP cache. Since fields and methods have different requirements, it would be possible to have two CP caches, one for fields and one for methods. The current CP cache code is rather "intense" because it is doing both chores at once.

For an CONSTANT_InvokeDynamic entry, the 24-bit index is probably unused. Instead, the instructions themselves point into a side table, much like today's cpCache, or perhaps the very same cpCache. Perhaps the root CONSTANT_InvokeDynamic entry points to a table with resources which make it easier to perform resolution, such as a resolved MethodType and name string. Or those resources could be associated in a table which is indexed by the first component of both indy and condy (the so-called "bootstrap specifier", an entry in the BootstrapMethods attribute).

If we do variant constants (where the constant value is contextual, the 24-bit index points to yet another table, an ordered pair of a sub-table (which can vary by context from an external source) and a short index into that table.