On 02/26/2015 01:02 AM, Charles Oliver Nutter 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.
* 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.
* 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.
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 :-)
That's off the top of my head. Others?
- Charlie
Hi,
What would be nice to have is support for constant direct method handles
and invokedynamic in Java language. We already have a syntax (thanks to
lambdas) and target typing. What I'm asking for is for the following...
constant direct method handles:
class C {
int someMethod(String s);
}
...
MethodHandle mh = C::someMethod(String);
No pre-bound MHs, no overloaded method resolution. Just plain
compilation to MH constant load.
invokedynamic:
There already was support for this in JSR292 prototype. Why was it removed?
If for nothing else, this would simplify writing tests and experiments.
Currently all we have is bytecode spinning with tools like ASM.
Regards, Peter
_______________________________________________
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
