MH.spreadArguments would certainly be useful from my point of view. We
have many cases where we need to take a trailing argument array and turn
it into some arguments, and array contain the remainder. This involves a
depressing amount of shuffling at the moment, and should be better.
On 26/02/2015 02:29, "John Rose" <john.r.r...@oracle.com> wrote:
>On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter <head...@headius.com>
>wrote:
>>
>> After talking with folks at the Jfokus VM Summit, it seems like
>> there's a number of nice-to-have and a few need-to-have features we'd
>> like to see get into java.lang.invoke. Vladimir suggested I start a
>> thread on these features.
>>
>> A few from me:
>>
>> * A loop handle :-)
>>
>> Given a body and a test, run the body until the test is false. I'm
>> guessing there's a good reason we don't have this already.
>
>A few reasons: 1. You can code your own easily.
>2. There's no One True Loop the way there is a One True If.
>The "run until test is false" model assumes all the real work is
>done with side-effects, which are off-center from the MH model.
>3. A really clean looping mechanism probably needs a sprinkle
>of tail call optimization.
>
>I'm not saying that loops should never have side effects, but I
>am saying that a loop mechanism should not mandate them.
>
>Maybe this is general enough:
>
> MHs.loop(init, predicate, body)(*a)
> => { let i = init(*a); while (predicate(i, *a)) { i = body(i, *a); }
>return i; }
>
>...where the type of i depends on init, and if init returns void then you
>have a classic side-effect-only loop.
>
>> * 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?)
>
>> * Argument grouping operations in the middle of the argument list.
>>
>> JRuby has many signatures that vararg somewhere other than the end of
>> the argument list, and the juggling required to do that logic in
>> handles is complex: shift to-be-boxed args to end, box them, shift box
>> back.
>
>We now have MHs.collectArguments. Do you want MHs.spreadArguments
>to reverse the effect? Or is there something else I'm missing?
>
>> Another point about these more complicated forms: they're ESPECIALLY
>> slow early in execution, before LFs have been compiled to bytecode.
>>
>> * 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.
>
>‹ John
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev@openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
