RFR: 8338967: Improve performance for MemorySegment::fill [v4]

Francesco Nigro duke at openjdk.org
Mon Aug 26 12:55:04 UTC 2024


On Mon, 26 Aug 2024 12:11:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 200:

> 198:             switch ((int) length) {
> 199:                 case 0 : checkReadOnly(false); checkValidState(); break; // Explicit tests
> 200:                 case 1 : set(JAVA_BYTE, 0, value); break;

beware using a switch, because if this code if is too big to be inlined (or we're unlucky) will die due to branch-mispredict in case the different "small fills" are unstable/unpredictable.
Having a test which feed different fill sizes per each iteration + counting branch misses, will reveal if the improvement is worthy even with such cases

test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java line 86:

> 84:     @Benchmark
> 85:     public void buffer_fill() {
> 86:         // Hopefully, the creation of the intermediate array will be optimized away.

This maybe won't....why not making the byte array a static final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731197802
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731199814


More information about the core-libs-dev mailing list