RFR: JDK-8302666: Replace CHM with VarHandle in ForeachOrderedTask [v4]

[Paul Sandoz]

On Tue, 28 Feb 2023 10:53:14 GMT, Viktor Klang <duke at 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