On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore <mcimadam...@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
