RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

Claes Redestad claes.redestad at oracle.com
Tue Jun 21 15:23:07 UTC 2016


Hi Michael,

this looks quite good to me.

Forgettable ramblings:

MethodTypeForm: could it be beneficial to have a cleaner to remove 
mappings from loopLambdaForms various LambdaForms are GCd?

InvokerBytecodeGenerator/IntrinsicMethodHandle: stringly typed 
localStateDesc seems like a wart to me. Since this is all package 
private, couldn't IntrinsicMethodHandle contain a @Stable Class<?>[] 
localStateTypes, then convert directly from List<MethodHandle> init to 
the class array in MethodHandleImpl::makeLoop etc:

         Class<?>[] localVarTypes = new Class<?>[init.size()];
         for (int i = 0; i < localVarTypes.length; i++) {
             Class<?> initRtype = init.get(i).type().returnType();
             localVarTypes[i] = 
BasicType.basicType(initRtype).basicTypeClass();
         }
         LambdaForm form = makeLoopForm(type.basicType(), localVarTypes);

The consuming code in InvokerBytecodeGenerator could then be simplified 
a bit on top of that: use arrays instead of List should be safe since 
it's private data that never escapes, the array from 
IntrinsicMethodHandle can be used directly when available etc.

/Claes

On 2016-06-20 08:49, Michael Haupt wrote:
> ... gentle reminder ... :-)
>
>> Am 16.06.2016 um 15:17 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>
>> Dear all,
>>
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/
>>
>> The change puts the tryFinally and loop method handle combinator implementations, which were introduced as part of the JEP 274 effort, on a LambdaForm basis, which executes in bytecode generating (default) and LambdaForm interpretation (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also changes the output formatting of LambdaForms, introducing a (hopefully) more readable format.
>>
>> Thanks,
>>
>> Michael
>



More information about the core-libs-dev mailing list