RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with Unsafe [v10]

[Maurizio Cimadamore]

On Thu, 20 Jul 2023 15:55:18 GMT, Glavo <duke at openjdk.org> wrote:

>>> In this result, ByteBuffer is much slower than VarHandle. Am I doing something wrong? What conditions are needed to make the performance of ByteBuffer close to that of Unsafe?
>> 
>> These are some benchmarks we have in the JDK:
>> 
>> Off-heap access:
>> 
>> 
>> Benchmark                       Mode  Cnt  Score   Error  Units
>> LoopOverNonConstant.BB_get      avgt   30  3.837 ± 0.045  ns/op
>> LoopOverNonConstant.unsafe_get  avgt   30  3.425 ± 0.032  ns/op
>> 
>> 
>> On-heap access:
>> 
>> 
>> Benchmark                           (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                 false  avgt   30  3.897 ± 0.055  ns/op
>> LoopOverNonConstantHeap.unsafe_get             false  avgt   30  3.446 ± 0.027  ns/op
>> 
>> 
>> BB is almost on par with unsafe. There's of course an extra bound check which you pay for. These benchmark are almost idential to the one you shared, so not sure what's going on.
>
> @mcimadamore I ran a series of experiments. When `ByteBuffer` is only used as a local variable without escaping, it is very close to `VarHandle`(`Unsafe`). However, any attempt to put the `ByteBuffer` into a field (even a static final field) resulted in the throughput drop of more than 50%.

I just ran your benchmark above - which is similar as I said to the ones we already have in the JDK. Results:

Benchmark                     Mode  Cnt  Score   Error  Units
ByteArray.readByte            avgt   30  3.619 ± 0.051  ns/op
ByteArray.readByteFromBuffer  avgt   30  3.936 ± 0.071  ns/op
ByteArray.readInt             avgt   30  3.653 ± 0.054  ns/op
ByteArray.readIntFromBuffer   avgt   30  3.798 ± 0.019  ns/op
ByteArray.readLong            avgt   30  3.637 ± 0.053  ns/op
ByteArray.readLongFromBuffer  avgt   30  3.922 ± 0.012  ns/op


I don't see 2x slowdown. Which JDK are you using? Which platform?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269675593