On Tue, 28 Feb 2023 10:53:14 GMT, Viktor Klang <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/stream/ForEachOps.java line 513: >> >>> 511: // of right subtree (if any, which can be this task's >>> right sibling) >>> 512: // >>> 513: var leftDescendant = (ForEachOrderedTask<S, >>> T>)NEXT.getAndSet(this, null); >> >> Casting the `null` is required for the resolved method descriptor to be >> `(ForEachOrderedTask, ForEachOrderedTask)ForEachOrderedTask` instead of >> `(ForEachOrderedTask, Object)ForEachOrderedTask`, which prevents unnecessary >> type conversion `LambdaForm`s from being introduced and allows >> [`VarHandle::withInvokeExactBehavior`] to be used: >> Suggestion: >> >> var leftDescendant = (ForEachOrderedTask<S, T>) >> NEXT.getAndSet(this, (ForEachOrderedTask<S, T>) null); >> >> >> [`VarHandle::withInvokeExactBehavior`]: >> https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/invoke/VarHandle.html#withInvokeExactBehavior() > > @ExE-Boss Ah, sorry, it was meant to be there. :) VarHandles are more optimized than MethodHandles when the signature at the call site does not match the signature of the handle. For referenced casts of arguments VarHandles avoid the `asType` conversion that would occur with method handles. This makes it much easier to write/read. VarHandle::withInvokeExactBehavior was introduced to deal with cases where an exact signature match is required. Sometimes this is useful to avoid performance potholes resulting from unintended primitive casts/conversions, where VarHandles otherwise resort to `asType` conversion. ------------- PR: https://git.openjdk.org/jdk/pull/12320
