Getting back into indy...need a better argument collector!

[Charles Oliver Nutter]

First attempt at a workaround seems to be a wash. I rolled back to my
older logic (that does not use a hand-crafted collector method) to
come up with a pure-MethodHandle workaround for asCollector. I came up
with this (using InvokeBinder):

```
MethodHandle constructArray = Binder.from(arrayType, Object[].class)
        .fold(MethodHandles.arrayLength(Object[].class))
        .dropLast()
        .newArray();

MethodHandle transmuteArray = Binder.from(arrayType, Object[].class)
        .fold(constructArray)
        .appendInts(0, 0, count)
        .permute(1, 2, 0, 3, 4)
        .cast(ARRAYCOPY.type().changeReturnType(arrayType))
        .fold(ARRAYCOPY)
        .permute(2)
        .cast(arrayType, arrayType)
        .identity();

MethodHandle collector = transmuteArray.asCollector(Object[].class,
count).asType(source.dropParameterTypes(0,
index).changeReturnType(arrayType));

return MethodHandles.collectArguments(target, index, collector);
```

Hopefully this is mostly readable. Basically I craft a chain of
handles that uses the normal Object[] collector and then simulates
what the pre-Jorn asCollector does: allocate the actual array we want
and arraycopy everything over. I figured this would be worth a try
since Jorn's comments on the PR hinted at the intermediate Object[]
going away for some collect forms. Unfortunately, reproducing the old
asCollector using MethodHandles does not appear to work any better...
or at least it still pales compared to a collector function.

I am open to suggestions because my next attempt will probably be to
chain a series of folds together that populate the target array
directly, but it will be array.length deep. Not ideal and not a good
general solution.

On Thu, Apr 1, 2021 at 6:44 PM Charles Oliver Nutter
<headius at headius.com> wrote:
>
> Very nice! I will have a look at the pull request and perhaps it will lead me to a short-term work around as well.
>
> On Thu, Apr 1, 2021, 12:04 Jorn Vernee <jorn.vernee at oracle.com> wrote:
>>
>> Hi Charlie,
>>
>> (Sorry for replying out of line like this, but I'm not currently
>> subscribed to the mlvm-dev mailing list, so I could not reply to your
>> earlier email thread directly.)
>>
>> I have fixed the performance issue with asCollector you reported [1],
>> and with the patch the performance should be the same/similar for any
>> array type (as well as fixing a related issue with collectors that take
>> more than 10 arguments). The patch is out for review here:
>> https://github.com/openjdk/jdk/pull/3306
>>
>> Cheers,
>> Jorn
>>
>> [1] : https://bugs.openjdk.java.net/browse/JDK-8264288
>>