[foreign-abi] RFR: 8247937: Specialize downcall binding recipes using MethodHandle combinators [v3]

[Jorn Vernee]

On Mon, 22 Jun 2020 11:31:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace errors
>
> Overall looks good, I've left a couple of minor editorial comments.
> 
> The architectural approach, while sound, to seems a bit risky. We're essentially adding yet another way to interpret
> bindings, and one that is less scrutable (since interpreting happens implicitly, via a MH chain) which will add cost in
> terms of maintenance going forwards. The speedup, seems good, but at the same time I can't help thinking that the basic
> binding interpreter has not been optimized much, so we don't really know how much of that performance gap is really due
> to the fact that interpreting bindings using a chain of MH is faster (I can see advantages in _not_ allocating the
> binding array, but other than that things look less obvious).  As a code organization strategy, I also wonder if it
> would pay off to bring more API to bindings, e.g. so that each binding could support a box/unbox/specialize triad of
> methods - rather than having switches scattered in several places?

I've applied your suggestion of putting the code for interpreting, verifying and specializing the Bindings in methods
on Binding itself, instead of scattered throughout the switch statements. This removes a bit of code as well, since
there is no more need for casting, and fields are directly accessible. There was one place where this didn't completely
work out; in the specialization we need to update the argument index (insertPos) when we encounter a MOVE binding, so
the code currently has to explicitly check for MOVE bindings.

I've also added a few more CallOverhead benchmarks, with a more diverse argument set. The results show that especially
once you start adding more arguments, or the arguments become more complex (see the MemoryAddress case), that the MH
specialization starts to make more of a difference.

Benchmark                                            Mode  Cnt     Score    Error  Units
CallOverhead.jni_blank                               avgt   30     8.415 □  0.076  ns/op
CallOverhead.jni_identity                            avgt   30    12.370 □  0.254  ns/op
CallOverhead.panama_args10                           avgt   30   583.976 □  5.895  ns/op
CallOverhead.panama_args10_NO_SPEC                   avgt   30  1319.897 □ 22.884  ns/op
CallOverhead.panama_args5                            avgt   30   502.865 □  8.452  ns/op
CallOverhead.panama_args5_NO_SPEC                    avgt   30   919.254 □ 11.101  ns/op
CallOverhead.panama_blank                            avgt   30   199.373 □  2.102  ns/op
CallOverhead.panama_blank_NO_SPEC                    avgt   30   317.260 □  4.067  ns/op
CallOverhead.panama_identity                         avgt   30   254.405 □  7.173  ns/op
CallOverhead.panama_identity_NO_SPEC                 avgt   30   494.224 □  2.359  ns/op
CallOverhead.panama_identity_memory_address          avgt   30   265.507 □  4.160  ns/op
CallOverhead.panama_identity_memory_address_NO_SPEC  avgt   30   592.381 □ 14.314  ns/op
CallOverhead.panama_identity_struct                  avgt   30   601.288 □ 16.147  ns/op
CallOverhead.panama_identity_struct_NO_SPEC          avgt   30   951.495 □ 15.450  ns/op

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/212