[foreign-memaccess+abi] RFR: Add support for high-level functions to copy to and from Java arrays [v4]

Maurizio Cimadamore mcimadamore at openjdk.java.net
Tue Jun 22 14:58:41 UTC 2021


On Tue, 22 Jun 2021 14:16:56 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> The performance is still a little bit slower for some query types (mainly facets), but I have the feeling this comes from the overhead when coyping small arrays, as well as scoping checks.
> 
> @mcimadamore: You mentioned that for small arrays, copy-loops may fit better. Do you have any suggestions what loop sizes we are talking about. Lucene's `long[]` are safely sizes <= 64 and `float[]` of sizes <= 1024 elements, so maybe it's a good idea to just use the default read loop and not specialize it to do bulk copy.

This does indeed look a lot better, thanks for testing. The issue with memory copy is that it adds unconditional memory barriers - so, in some circumstances it can cause performance degradation. If you copy in a loop, you use Unsafe::get/put and those will only add barriers if access is on-heap.

We have a bug to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8269119

In terms of sizes, I think the ByteBuffer API used to avoid copying for extremely small sizes, (6 logical elements, if I'm correct).

I also think that there are other performance potholes around bound checking (as we speak, we're investigating one mentioned here [1]) and some of those will not be even addressable until we get proper support for long loop optimizations [2].

So, we know that, performance-wise, we're still not 100% there, but it seems like we're getting closer.

[1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-June/014260.html
[2] - https://github.com/openjdk/jdk/pull/2045

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

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


More information about the panama-dev mailing list