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
