On Mon, 26 Aug 2024 12:11:29 GMT, Per Minborg <pminb...@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: >> >>  >> >> 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
