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.ha...@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
