RFR: 8257074 Update the ByteBuffers micro benchmark

[Chris Hegarty]

On Wed, 25 Nov 2020 13:37:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks like a good cleanup. I agree that mixing access and instantiation is not good from a benchmark perspective - although, given that direct buffers have a rather convoluted allocation process, I guess it would be useful, in the long term, to track performances of that too (this can be done by coupling direct buffer allocation with calls to Unsafe::invokeCleaner, so that the benchmark is not affected by the GC activity).

I'll see if I can write a test for this.

> Also, given a carrier e.g. `float` there are at least two ways to get a float from a byte array:
> 
> * ByteBuffer::getFloat (both direct/heap)
> * FloatBuffer::get() (both direct/heap)
> 
> The benchmark here focuses on the first bullet, but I think at some point we should also cover the remaining axis, so that, for each carrier, we really do at least 4 tests. Of course if you take into account swappiness for non-byte carriers, you get an extra variant for direct buffers as well, as you wanna test native endian vs. non-native endian.

Yes, good observation - I had similar thoughts. Let me check if we could easily integrate some of these variants. What I'm trying to end up with is a comprehensive(ish) set of test scenarios that can be used to analyse performance ( of which views and endianness are important).

It may be reasonable for this particular benchmark to include views, etc, with appropriately named benchmark methods, so that one can easily run a subset, e.g. "org.openjdk.bench.java.nio.ByteBuffers.test(Direct)?(BulkPut|SinglePutByte)", when trying to "zoom in" on a specific code path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430