RFR: 8299962: Speed up compiler/intrinsics/unsafe/DirectByteBufferTest.java and HeapByteBufferTest.java

[Emanuel Peter]

On Thu, 12 Jan 2023 23:00:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The test used a blanket `100_000` iterations to ensure C2 triggers for the relevant intrinsics of `jdk.internal.misc.Unsafe`.
>> 
>> I experimented lowering the number of iterations, and got the following results:
>> `100_000` (overkill, 8.5 sec) `5000`(very safe, 3 sec), `2000`(decent, 2.6 sec) and even `200` (ok, 2.5 sec).
>> I measured the time per `@run` statement (there are 6 over the two test files).
>> 
>> For `5000` I got the same count of intrinsifications per intrinsic.
>> For `2000` it dropped slightly, rarely an intrinsic was not intrinsified.
>> For `200` it dropped a bit more, and sometimes multiple intrinsics are not intrinsified.
>> 
>> If one uses `-Xbatch -X:-TieredCompilation`, then the cound does not change at all, even for `200`.
>> 
>> Since the marginal speedup from `5000` to `200` is very small, I decided to be on the **safe side**.
>> This is still a **speedup of 2.7x**.
>
> Thank you for explanation. Looks good.
> 
> `ByteBufferTest::stepUsingAccessors()` code is not C2 friendly because it will get profiling data only for first loop before triggering OSR and full compilation. Which may cause deoptimization and recompilation when it hit following loops. That is may be why `iterations` value was so high to make sure profiling data is collected for all loops.
> 
> The test should have separate methods for each type of intrinsics.

@vnkozlov I filed a follow up RFE with your suggestion for improvement: [JDK-8300187](https://bugs.openjdk.org/browse/JDK-8300187)

Thanks for the help and reviews @vnkozlov @TobiHartmann

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

PR: https://git.openjdk.org/jdk/pull/11944