On Mar 6, 2015, at 5:30 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com>
wrote:
>
>>> * try/finally as a core atom of MethodHandles API.
>>>
>>> Libraries like invokebinder provide a shortcut API To generating the
>>> large tree of handles needed for try/finally, but the JVM may not be
>>> able to optimize that tree as well as a purpose-built adapter.
>>
>> I agree there. We should put this in.
>>
>> MHs.tryFinally(target, cleanup)(*a)
>> => { try { return target(*a); } finally { cleanup(*a); } }
>>
>> (Even here there are non-universalities; what if the cleanup
>> wants to see the return value and/or the thrown exception?
>> Should it take those as one or two leading arguments?)
> Probably, it's too much. Result-agnostic cleanup logic looks like the
> cleanest solution from API perspective.
>
> There are catchException and foldArguments/filterReturnValue to combine with.
> Or am I missing something?
As Charlie has explained, try/finally is *just barely* doable with the existing
API points, as you note. I think we want a composite API point which can be
readily compiled down to the natural JVM operations, instead of requiring the
user to emit a complex pattern. The complex pattern will probably not be
recognizable, and so won't be compiled down to the simple JVM operations.
>
>>> * Implementation-specific inspection API.
>>>
>>> I know there are different ways to express a MH tree on different JVMs
>>> (e.g. J9) but it would still be a big help for me if there were a good
>>> way to get some debug-time structural information about a handle I'm
>>> using. Hidden API would be ok if it's not too hidden :-)
>>
>> Idea of the day: An ASM-like library for method handles.
>> Make a MethodHandleReader which can run a visitor over the MH.
>> The ops of the visitor would be a selection of public MH operations
>> like filter, collect, spread, lookup, etc.
>> Also ASM-like, the library would have a MethodHandleWriter
>> would could be hooked up with the reader to make filters.
> Not sure how useful it would be for an API user. I find it hard to recover MH
> transformation chains from MethodHandle trees, since the representation we
> use is quite low-level. They end up as trees of BoundMethodHandles and you
> can guess the intention only by carefully inspecting LambdaForms.
Yes, that's probably the downside. But (remaining hopeful) even if decoding
the LF will not recover the original MH transformation chain, it may recover an
*equivalent* one.
> You can try it yourself by turning on
> -Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true and calling
> MethodHandle.toString() on a method handle of your choice.
That's the first thing for a customer to try.
— John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
