> 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