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. ------------- Commit messages: - DontInline slow path in MethodHandle::asType - Fix bench - Use different classloaders - Disable tiered compilation - Add benchmark Changes: https://git.openjdk.org/jdk/pull/21283/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21283&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341127 Stats: 145 lines in 2 files changed: 143 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21283.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21283/head:pull/21283 PR: https://git.openjdk.org/jdk/pull/21283
