RFR: 8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline [v4]

[Maurizio Cimadamore]

On Tue, 1 Oct 2024 22:51:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I don't have a clear understanding how `VarHandleGuards` is used, but I assume that `MethodHandle::asType` calls there are no-ops in scenarios you care about.

A var handle guard is a piece of code that detects var handle call of a certain shape, to avoid creation of lambda forms in some common cases. This was done in Java 9, and was unchanged by FFM. In this case, we just happen to hit the var handle guard for `(LJ -> J)`. And yes, the asType adaptation is a no-op here.

The difference is that in the normal code path (lambda form), the call to `asType` is guarded by a check:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L513

Normally, var handle guards don't need an `asType` adaptation:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java#L230

But if a var handle guard is triggered on an "indirect" var handle (read:  a var handle that has been adapted with some combinator - this part is new since FFM), then we go through a different path in the guard code which _always_ calls `asType`:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java#L233

(note: this "slow path" inside var handle guards predates FFM, but var handle adaptation has increased the number of cases in which we hit this slow path).

The PR that introduced this regression made all FFM var handles undergo some adaptation. Which is why now we're seeing this issue - as we're now hitting a (no-op) `asType` call which was never made before.

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2388712441