On Wed, 25 Nov 2020 13:37:48 GMT, Maurizio Cimadamore <mcimadam...@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
