RFR: 8257074 Update the ByteBuffers micro benchmark [v2]

[Chris Hegarty]

> 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