> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically, the impact of such changes on the performance of sharp
> memory access operations.
>
> This issue proposes to update the benchmark in the following ways to meet the
> aforementioned use-case:
>
> 1. Remove allocation from the individual benchmarks - it just creates noise.
> 2. Consolidate per-thread shared heap and direct buffers.
> 3. All scenarios now use absolute memory access operations - so no state of
> the shared buffers is considered.
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box.
> 5. There seems to have been an existing bug in the test where the size
> parameter was not always considered - this is now fixed.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
Add additional carrier views and endianness variants.
A large number of variants are now covered. The individual benchmarks conform
to the following convention:
test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
This allows to easily run a subset of particular interest. For example:
Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
Char only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
Bulk only :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
Put with Int or Long carrier :-
test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
Running all variants together is likely not all that useful, since there will
be a lot of data.
The param sizes are changed so as to better allow for wider carrier views.
There are a lot of individual benchmark methods, but their implementation is
trivial, and largely mechanical.
Question: where do folk stand on having a `main` method in a benchmark - as a
standalone-run sanity? I found this useful to assert the validity of the
benchmark code. It can be commented out if it could somehow affect the
benchmark runs.
( I omitted read-only views, since they less interesting, and we already have
a lot of variants )
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1430/files
- new: https://git.openjdk.java.net/jdk/pull/1430/files/5e91e63e..84dabc30
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=00-01
Stats: 1022 lines in 1 file changed: 995 ins; 1 del; 26 mod
Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430
PR: https://git.openjdk.java.net/jdk/pull/1430
