On Tue, 1 Oct 2024 10:08:54 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
> The fix for JDK-8331865 introduced an accidental performance regression. > The main issue is that now *all* memory segment var handles go through some > round of adaptation. > Adapting a var handle results in a so called *indirect* var handle. > When an indirect var handle is called through a *var handle guard*, an extra > `MethodHandle::asType` call is triggered. > In some cases, if `asType` has already been compiled into a big method, it > cannot be inlined into the caller, which then results in a failure to inline > through the var handle call, resulting in a big performance regression. > > The solution is to make sure that the compiled size of `MethodHandle::asType` > stays small: this is done by making sure that the slowpath (the one which > populates the cache used by `asType`) is not inlined by the JVM. This is done > by consolidating the slow path into a separate method, which is annotated > with the internal `@DontInline` annotation. > > This problem was originally reported here: > https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html > > While we did not test this fix directly, we have made sure that running the > problematic benchmark with the flags: > > > -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache > -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached > > > Solves the performance regression. The fix in this PR is just a programmatic > way to achieve the same results w/o the need of command line flags. This pull request has now been integrated. Changeset: 7fa2f229 Author: Maurizio Cimadamore <mcimadam...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/7fa2f229fbee68112cbdd18b811d95721adfe2ec Stats: 152 lines in 2 files changed: 150 ins; 0 del; 2 mod 8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline Reviewed-by: psandoz, redestad, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/21283
