hg: valhalla/valhalla/langtools: Add experimental support for generic class literals

[John Rose]

On Aug 18, 2014, at 8:59 AM, David Chase <david.r.chase at oracle.com> wrote:

> I’m still working the “how do I help the optimizer” angle and I don’t think I’m done with that, but I there’s
> a place where it would be really helpful (from the POV of predictable high performance) if I were able
> to say “right here, specialize this, and propagate some code constants please”.

In the C++ world, that is sometimes done by instantiating a template with a function argument.

It's worth keeping this trick in mind, especially given that our VM-internal representation for specialization is likely to use something like a BSM, which can take arguments that are not only a Class but also a MethodHandle.

Another way to think about the problem (at a lower level) is to imagine that your generic algorithm code is a method which takes two sets of arguments, one for instantiation and one for execution.  Then do a partial application using MethodHandles.insertArguments to deliver the instantiation parameters of the loop, and somehow request/expect a high level of specialization on the internals of the MH, prior to applying the rest of the arguments (perhaps many times) with MethodHandle.invoke.

If the arguments can be separated more clearly between a factory method and an execute method, all the better, though I think user-friendly applications might allow the user to specify the computation in a fluid mix of instantiation and execution parameters.  Some languages use rich static types or DSLs to manage the static parts.

In either case, the idea of partial application, followed by optimization, would present very well via an invokedynamic instruction and/or a classdynamic reference.  Such a two-step pattern is harder to present via builder APIs (like our streams API), because it is not clear how to perform the instantiation part statically; it has to happen "on the fly" every time a stream object is created, requiring caching strategies.

Perhaps there's a lightweight way to hook into invokedynamic from a Java API in a way that would allow the BSM to fish through the call site and glean the instantiation information somehow at link time.

Or maybe we need a more frontal attack on the problem, by means of "collection literals", which (surprise, surprise) really turn out to be extensible DSLs.

Or maybe there's a way after all to do everything with invokeinterface and inlining; we just need some missing gesture to deftly turn on customization-driven inlining.

(We can think of lots of notational options, but the real puzzle is how to get the new powers we want with the smallest number of cuts to the language and VM.  It's really great that we are making trial cuts now.)

— John