The invokedynamic bytecode points to one JVM_CONSTANT_InvokeDynamic Constant Pool entry but requires resolution information for each occurrence in the bytecode stream. To implement this, we appended to the CP cache and changed the indexes in the bytecode accordingly. This seems simple enough but it gets complicated because invokespecial may also add a cpCache entry:

// If the constant pool entry for invokespecial is InterfaceMethodref,
// we need to add a separate cpCache entry for its resolution, because it is
// different than the resolution for invokeinterface with InterfaceMethodref.
// These cannot share cpCache entries.

Also, for CDS, we need to not clear the f2 field because that's where the resolved references index is.

For RedefineClasses, the appended cp Cache might be wrong for old methods running if they try to use the merged constant pool with an invokedynamic bytecode (which right now they do not - they stay with their local constant pool).

And of course, fields called indices, f1, f2 and flags are not really helpful in understanding what invokedynamic resolution information really means.