[External] : Re: Potential performance regression with FFM compared to Unsafe

[Chen Liang]

Hi Tomer,
Note that your way of accessing the layout might not be the best; our recommended way of element access is to construct a larger layout (like a group layout representing a struct), and then obtain var handles with varHandle(PathElement). These var handles perform the same access checks, and these duplicate checks might be merged into one by the JIT compiler; such is called "loop hoisting" and is seen in JDK benchmarks. I haven't got time to try this out on your benchmarks yet, but I hope this might be able to address some of the regressions you have observed.

In addition, for particular structs, we are planning record and interface mappers; record mappers perform a single read to copy native data to immutable objects, while interface mappers are more memory efficient and lazy, but can suffer from memory tearing issues. Those might be useful for the different scenarios you have mentioned as well.

Chen
________________________________
From: Tomer Zeltzer <tomerr90 at gmail.com>
Sent: Friday, April 18, 2025 4:45 PM
To: Chen Liang <chen.l.liang at oracle.com>
Cc: panama-dev at openjdk.org <panama-dev at openjdk.org>
Subject: [External] : Re: Potential performance regression with FFM compared to Unsafe


Thank you for testing this out Chen!
A number of other people were able to reproduce the on heap results so not sure what to say here but thats the less important conclusion I think.
For off heap, having the memory segment as a final field sounds like something that can be relevant for a very few niche use cases, if at all...
If this cant be optimized further, without the final, this means a significant performance hit for a lot of use cases... off the top of my head, libraries like zstd and gzip that do jni bindings

On Fri, Apr 18, 2025, 01:17 Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
Hello, I think the observed performance difference is probably due to the heap array being static final. I tested on latest mainline, and ffm is consistently slower without a static final object that it can constant fold against: it exhibited similar performance for auto arena 100 vs byte array 100, both having a significant overhead compared to Unsafe, unless the byte array is a constant (in a static final field). Meanwhile, I cannot reproduce FFM being faster than Unsafe for heap access: in the best case FFM is still slightly slower than Unsafe.

For context, I used the source code at https://github.com/tomerr90/UnsafeVSFMA/blob/main/src/main/java/org/example/FMASerDe.java<https://urldefense.com/v3/__https://github.com/tomerr90/UnsafeVSFMA/blob/main/src/main/java/org/example/FMASerDe.java__;!!ACWV5N9M2RV99hQ!Lxvv0mXLndq2JUXA3nMUEyn-744ytcvs5eJAjifpuCqRoGtqtYNwPrN8QnhNzqGoP2hkW7qBYd1IkVXpAIs$> and edited around. I recommend testing against 22 or later releases where FFM has finalized; the preview feature on 21 is no longer maintained.

Regards, Chen Liang
________________________________
From: panama-dev <panama-dev-retn at openjdk.org<mailto:panama-dev-retn at openjdk.org>> on behalf of Tomer Zeltzer <tomerr90 at gmail.com<mailto:tomerr90 at gmail.com>>
Sent: Thursday, April 17, 2025 6:31 AM
To: panama-dev at openjdk.org<mailto:panama-dev at openjdk.org> <panama-dev at openjdk.org<mailto:panama-dev at openjdk.org>>
Subject: Potential performance regression with FFM compared to Unsafe

Hey all!
First time emailing such a list so apologies if somwthing is "off protocol".
I wrote the following article where I benchmarked FFM and Unsafe in JDK21
https://itnext.io/javas-new-fma-renaissance-or-decay-372a2aee5f32<https://urldefense.com/v3/__https://itnext.io/javas-new-fma-renaissance-or-decay-372a2aee5f32__;!!ACWV5N9M2RV99hQ!Lxvv0mXLndq2JUXA3nMUEyn-744ytcvs5eJAjifpuCqRoGtqtYNwPrN8QnhNzqGoP2hkW7qBYd1IekAyXVw$>

Conclusions were that FFM was 42% faster for on heap accesses while 67% slower for off heap, which is a bit weird.
Code is also linked in the article.
Would love hearing your thoughts!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250418/bf2edd9e/attachment-0001.htm>