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

[Glavo]

On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> > it's likely to introduce non-trivial additional overhead
>>> 
>>> What do you mean? E.g. where would the overhead come from?
>> 
>> You suggested changes stored the ByteBuffer into a field. I measured throughput with JMH, and it shows that using ByteBuffer like this results in over 50% drop in throughput.
>
>> 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%.

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

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