FFM API: EA failure with 4+ address parameters

[Maurizio Cimadamore]

My hunch was correct. When tweaking the acquire code I go from this:

|Benchmark Mode Cnt Score Error Units FFMEscapeAnalysisTest.noop_params0 
avgt 3 6.243 ± 0.221 ns/op FFMEscapeAnalysisTest.noop_params1 avgt 3 
6.243 ± 0.301 ns/op FFMEscapeAnalysisTest.noop_params2 avgt 3 6.198 ± 
0.056 ns/op FFMEscapeAnalysisTest.noop_params3 avgt 3 6.533 ± 1.222 
ns/op FFMEscapeAnalysisTest.noop_params4 avgt 3 17.435 ± 1.990 ns/op 
FFMEscapeAnalysisTest.noop_params5 avgt 3 21.509 ± 4.035 ns/op |

To this:

|Benchmark Mode Cnt Score Error Units FFMEscapeAnalysisTest.noop_params0 
avgt 3 6.479 ± 0.052 ns/op FFMEscapeAnalysisTest.noop_params1 avgt 3 
6.230 ± 0.016 ns/op FFMEscapeAnalysisTest.noop_params2 avgt 3 6.272 ± 
0.082 ns/op FFMEscapeAnalysisTest.noop_params3 avgt 3 6.566 ± 0.294 
ns/op FFMEscapeAnalysisTest.noop_params4 avgt 3 6.200 ± 0.066 ns/op 
FFMEscapeAnalysisTest.noop_params5 avgt 3 6.785 ± 0.029 ns/op |

So, something is definitively off with that acquire code.

Thanks for the report!
Maurizio

On 23/10/2024 17:21, Maurizio Cimadamore wrote:

> Thanks Ioannis, we'll take a look.
>
> One thing that comes to mind is that when you pass an address to a 
> downcall, the Linker has to keep its arena alive (to ensure it stays 
> alive for the entire duration of the call). Now, if the segments you 
> pass are constructed with MemorySegment::ofAddress, you get back 
> segments associated with the global scope, so this "acquire" operation 
> is a no-op.
>
> But the Linker-generated code contains some non-trivial logic to try 
> to reduce the number of acquire calls that are generated - e.g. if you 
> pass 7 arguments all associated with the same arena, we'll just do a 
> single acquire. I wonder if, as the number of argument becomes 
> increasingly big, the generated code for the downcall bindings becomes 
> too complex and full of control flow, which then results in EA bailing 
> out.
>
> (Needless to say, we can't wait to make MemorySegment implementation a 
> value class and avoid all these issues :-) )
>
> If that is the issue, it might be that case that calling one acquire 
> per pointer argument, even if redundant, leads to better optimizations 
> than what we have now. The complex logic I'm referring to is here:
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java#L497 
>
>
> Maurizio
>
> On 23/10/2024 16:51, Ioannis Tsakpinis wrote:
>> Hello,
>>
>> I've been migrating LWJGL to FFM and during testing of some real-world
>> code (Vulkan rendering), I noticed a spike in GC activity with the FFM
>> implementation, compared to the old JNI implementation. I think I've
>> been able to track it down to what looks like an odd failure of escape
>> analysis. Specifically, scalar replacement no longer occurs when
>> calling functions with 4 or more ADDRESS (MemorySegment) parameters.
>>
>> JMH benchmark (you'll need to build a shared library with some empty
>> functions and run with GC profiling enabled) that demonstrates the
>> issue:
>>
>> https://gist.github.com/Spasi/71d5cfa687a1dbe95b3fce608d31ae6b
>>
>> There are functions with arity from 0 to 5. When invoking a downcall,
>> raw pointer values are wrapped with MemorySegment.ofAddress() and
>> passed to each argument. The exact pointer values do not matter.
>>
>> Until 3 ADDRESS parameters, or 3 ADDRESS parameters plus other non-
>> ADDRESS parameters, everything is fine and there's no GC activity.
>> With 4 or more ADDRESS parameters, allocations are no longer
>> eliminated. The problem also occurs with a single MemorySegment that
>> is passed to all parameters:
>>
>> var p = MemorySegment.ofAddress(42L);
>> functionMH.invokeExact(p, p, p, p);
>>
>> Any idea what might be causing this?
>>
>> - Ioannis

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241023/54f210e0/attachment-0001.htm>