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