unexpected allocation of Binding.Context in downcall method handle

[Maurizio Cimadamore]

Hi Rado,
honestly this seems to be in the noise.

I did some more experiments and it seems that, while the implementation 
is not optimal, EA kicks when we create an unused Binding.Context, which 
makes it harder to spot differences.

I think this code will likely change significantly as part of:

https://bugs.openjdk.java.net/browse/JDK-8278414

So we can probably make sure to avoid a context allocation as much as 
possible when we rewrite things. Yesterday I did another pass on the 
code and I was reminded that there are actually two contexts - one is 
the one used by the caller - which is used e.g. to allocate a return 
struct. The other is an internal context which is used to allocate 
intermediate data during the upcall.

The extra allocation removed in my patch actually refers to the former, 
and not the latter (as I originally suggested).

Maurizio

On 17/12/2021 20:30, Rado Smogura wrote:
> Hi all,
>
>
> Sorry if it will not be in thread, but I had to re-register. And thank 
> you for fast response.
>
>> Hi,
>> following the discussion on [1], here is a quick patch which attempts to
>> remove the additional allocation:
>>
>> https://github.com/mcimadamore/jdk/pull/new/avoid_context_alloc
>>
>> I'm not able to see any gain using synthetic benchmarks, but perhaps
>> worth a try to confirm that this is really the issue we're seeing?
>>
>> Thanks
>> Maurizio
> I think this change could be hard to spot on benchmarks  (on debugger 
> I don't see Binding.Context.ofAllocator called). I guess it's about 
> few hardware instructions.
>
> I slightly changed existing benchmark [1]
>
> public void setup() {
>     constString =MemorySegment.allocateNative(str.length() 
> +1,ResourceScope.globalScope());
>     constString.setUtf8String(0,str);
> }
>
> @Benchmark public int panama_strlen_noalloc()throws Throwable {
>     return (int)STRLEN.invokeExact((Addressable)constString);
> }
>
> And results are as follow
>
> After
> Benchmark                         (size)  Mode  Cnt   Score Error  Units
> StrLenTest.panama_strlen_noalloc       5  avgt   20  12.680 ± 0.451  
> ns/op
> StrLenTest.panama_strlen_noalloc      20  avgt   20  12.361 ± 0.026  
> ns/op
> StrLenTest.panama_strlen_noalloc     100  avgt   20  12.510 ± 0.168  
> ns/op
>
>
> Before (3f9638d124076019f49eb77bc3ff8b466e4beb53)
>
> Benchmark                         (size)  Mode  Cnt   Score Error  Units
> StrLenTest.panama_strlen_noalloc       5  avgt   20  12.837 ± 0.515  
> ns/op
> StrLenTest.panama_strlen_noalloc      20  avgt   20  12.471 ± 0.129  
> ns/op
> StrLenTest.panama_strlen_noalloc     100  avgt   20  12.537 ± 0.395  
> ns/op
>
> Theoretically it's 1% gain, but it's as well can be in error margin.
>
> [1] 
> https://github.com/rsmogura/panama-foreign/commit/e10e20f89767747c24f657d2cd5de6b7fc9a934c
>
> Kind regards,
> Rado
>