ConstantDynamic: Building ROM and RAM Classes

[tajila]

Marking CPEntries

Marking which CP entries are used by ldc will have to be updated to account for Condy entries.

computeConstantMapAndSizes will also have to be updated to include Condy CP entries.

Add new CP entry type

Add new CP description types to BCT_J9DescriptionCPType and J9DescriptionBits (j9nonbuilder.h) for Condy. This will be used to detect the CP type in the bytecode interpreter during ldc (ldc_2 and ldc2_w) bytecodes.

Update ConstantPoolWriter (RomClassWriter.cpp) to add visitCondyType. This will write out CP entries for Condy in the romConstantPool. The first CP entry slot is a SRP to the NameAndSignature. The second slot is the bootstrap Method index or’ed with the J9DescriptionCPType.

Slot1: SRP to NAS

Slot2: Index of BSM (shifted up by 4) | Cptype

This matches the RomStringRef type

typedef struct J9ROMStringRef {
	J9SRP utf8Data;
	U_32 cpType;
} J9ROMStringRef;

The first 4bits of second slot in the romCPEntry must contain the cpType. This is checked by the ldc bytecode to determine what type of resolution to perform for the cp entry.

Update constantPoolDo in ConstantPoolMap for the new cp entry.

RamClass layout

The ramConstantPool entry for Condy is:

Slot1: (j9object_t) Constant

Slot2: (j9object_t) exception

This is done to match existing RamStringRefs. By convention the first slot is NULL checked to see if the ref requires resolution. For this reason the Condy constant must be the first slot.

typedef struct J9RAMStringRef {
	j9object_t stringObject;
	UDATA unused;
} J9RAMStringRef;

[DanHeidinga]

Add new CP description types to BCT_J9DescriptionCPType and J9DescriptionBits (j9nonbuilder.h) for Indy and Condy.

As you pointed out on the whiteboard, moving Indy CP entries back into the constantpool will increase the romclass size slightly in the common case of invokedynamics not sharing cp entries.

This design can do the Condy side and leave the Indy representation as is.

[DanHeidinga]

The layout of the ROM / RAM cp entries must match the layout of Constant_Class / Constant_String entries due to the resolution check in the ldc bytecode. It treats all ldc-able constants as having a common shape and null-checks the first(?) slot as a resolve check. After that it differentiates by type.

[tajila]

As you pointed out on the whiteboard, moving Indy CP entries back into the constantpool will increase the romclass size slightly in the common case of invokedynamics not sharing cp entries.

I wasn't sure if we reached a consensus yesterday. I have updated the design to exclude InvokeDynamic.

The layout of the ROM / RAM cp entries must match the layout of Constant_Class / Constant_String entries due to the resolution check ...

Yes, they currently match. I've added the existing String CPentries to the design for comparison

[DanHeidinga]

@fengxue-IS Are you looking at this?