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

Vladimir Kozlov kvn at openjdk.org
Fri Jan 13 04:02:40 UTC 2023


On Wed, 11 Jan 2023 13:51:16 GMT, Emanuel Peter <epeter 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.

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

Marked as reviewed by kvn (Reviewer).

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


More information about the hotspot-compiler-dev mailing list