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:
Good point, Claes. But BasicType[] looks like a better fit.
Unfortunately, it can't be used as a key into the cache, so some
flattening is needed.
Best regards,
Vladimir Ivanov
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
