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
