RFR: 8264762: ByteBuffer.byteOrder(BIG_ENDIAN).asXBuffer.put(Xarray) and ByteBuffer.byteOrder(nativeOrder()).asXBuffer.put(Xarray) are slow [v2]

Brian Burkhalter bpb at openjdk.java.net
Mon Apr 26 21:41:36 UTC 2021


On Mon, 26 Apr 2021 21:35:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this request to accelerate absolute and relative bulk array transfer on views of heap byte buffers where the element size is greater than one. What currently happens is that the transfer devolves to a “loopy” element-by-element copy such as
>> 
>>         int end = offset + length;
>>         for (int i = offset, j = index; i < end; i++, j++)
>>             dst[i] = get(j);
>> 
>> for `get()`, and
>> 
>>         int end = offset + length;
>>         for (int i = offset, j = index; i < end; i++, j++)
>>             this.put(j, src[i]);
>> 
>> for `put()`. This is of course relatively slow.
>> 
>> The change proposed hoists the accelerated versions of these methods using the `ScopedMemoryAccess` methods `copyMemory()` and `copySwapMemory()` from `Direct-X-Buffer` to `X-Buffer`. The array bulk transfer methods are removed from `Direct-X-Buffer` itself. The number of lines of code in the templates decreases by 87.
>> 
>> With this change the throughput of array bulk `put()` and `get()` for heap view buffers is increased by a factor of 6 to 11 compared with the current code. The performance of direct view buffers does not appear to be affected.
>> 
>> No tests are modified or added as existing tests already cover these methods. All tests in CI tiers 1-3 passed on all platforms.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264762: In X-Buffer use $.BYTES instead of ELEMENT_SIZE; remove useless ReadOnlyBufferException from getArray().

I verified that there is indeed inconsistency in the order of checks done in the absolute and relative bulk operations. The checking order is however the same before and after the commits in this request are applied. It might be better to defer any change in the order of checks to a separate issue.

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

PR: https://git.openjdk.java.net/jdk/pull/3660


More information about the nio-dev mailing list