What can we improve in JSR292 for Java 9?

[John Rose]

On Feb 25, 2015, at 4:02 PM, Charles Oliver Nutter <headius at 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