Constant_Dynamic first experiences

[John Rose]

On Jul 3, 2018, at 12:13 PM, Ghadi Shayban <gshayban at gmail.com> wrote:
> 
> Thank you both.
> 
> For _nested constant aggregates_, I'll try John's leaf+steering suggestion, but that will take a bit more surgery.

We are thinking about a generically reusable way to do
leaves-plus-expression-steering; a working title is invokeMultiple.
It would generalize the Java 11 BSM named ConstantBootstraps.invoke.

https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/lang/invoke/ConstantBootstraps.html#invoke(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.Class,java.lang.invoke.MethodHandle,java.lang.Object...)


> Re: getting rid of array bytecode boilerplate, I tried a few things in the context of making a _non-constant_ vector.
> 
> Emission styles:
> A)
> push MethodHandle for clojure.lang.RT.vector(Object...)
> push all elements
> signature polymorphic call to MH.invoke

This is going to be slower because the MH that receives the
MH.invoke call will have to dynamically adjust to all the various
signatures presented to it by all the various call sites.

> B) 
> push all elements
> invokedynamic, with BSM returning a CCS around RT.vector(Object...), adapted for the incoming signature with asType()

That's better.  In that case, the asType adaptation is done once per
call site instead of once per call.  (MH.invoke calls MH.asType.)

> C) same as B but the CallSite+MH is memoized for arities <= 6 using asCollector()

That might be an improvement.  We could do something like this
inside of AsVarargsCollector but choose to use a one-element cache.

> All of these worked but had a slight startup regression, more severe in approach A (~0.65s -> ~0.85s).
> I'm not sure whether I am using MH combinators properly, or invoke vs invokeExact.

B or maybe C is the right way to use the machinery.  Claes might
be right about why you are seeing a regression.

— John