ConstantDynamic: Resolving Constant_Dynamic entries

[tajila]

LDC bytecode

The ldc bytecode will have to be modified to detect Condy constants. If the constant or exception doesn’t exist in the ramConstantPool attempt to resolve the constant. If the exception exists throw the exception (Note: if LDC of Condy causes an exception, the same exception must be thrown every time). If the constant exists return the constant.

LDC2lw bytecode

The ldc2_w byte will check the cp type via something like `J9_CP_TYPE(cpShapeDescription, cpIndex)`. If it is not a Condy entry normal execution will occur. If it is, romConstantPool entry will be NULL check for the Condy constant, then for the exception. If both are NULL then resolution will occur. When the constant is resolved the long or double will be extracted from the object with something like `J9VMJAVALANGLONG_VALUE` and then placed on the stack.

Resolving native side

Create a new helper in resovleSupport to resolve Condy CPentries. This can share a common helper with `resolveInvokeDynamic` as much of the functionality will be the same.

In the case of Condy, the helper will need to fetch the nameAndSig and bsmIndex from the romCP entry. Otherwise, the rest of the calculations required to determine the start bsmData are the same as with Indy

The helper will call sendResolveConstantDynamic (new function) to retrieve and run the BSM for the LDC. After the result will be cached in the ramConstantPool it is Condy.

In the Condy case the helper will check if an exception was thrown upon returning from sendResolveConsntantDynamic. If an exception exists, it will be stored in the exception slot in the ramConstantPool entry.

sendResolveConstantDynamic will be similar to sendResolveInvokeDynamic, it will perform a java call-in to MethodHandle.resolveConstantDynamic()

Resolving Java side

A new function `MethodHandle.resolveConstantDynamic()` will need to be added, this can share a common helper with `MethodHandle.resolveInvokeDynamic` as much of the code is the same. A boolean can be added the helper args to identify whether it is resolving for Condy or Indy.

If Condy is detected the third parameter to the staticArgs array with be a Class instead of a MethodType. A new entry will have to be added for Condy when marshalling the args. And a new native will have to be added to java_dyn_methodhandle.c to retrieve the a CondyConstant (to start we can avoid putting Condy constants in args until the native is implemented #1276). If resolving for Condy the invokeWithArgs stage will cast and return an Object rather than a Callsite. The result will be validated based on the steps specified in the spec and then returned. If an exception occurs the exception is thrown.

[DanHeidinga]

resolveInvokeDynamic will be modified to retrieve the bsmIndex and nameAndSig from the romCP entry instead of the romClass callsiteData.

Given the whiteboard discussions yesterday and the decision to defer moving indy cp entry data back into the constantpool, does this still apply?

[tajila]

I have modified the design