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

Maurizio Cimadamore mcimadamore at openjdk.org
Thu Jul 20 15:51:41 UTC 2023


On Thu, 20 Jul 2023 15:43:01 GMT, Glavo <duke 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?
>
>> > 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.

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

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


More information about the core-libs-dev mailing list