On Sun, 13 Sep 2026 03:59:51 GMT, Chen Liang <[email protected]> wrote:
>> Implement a method handle combinator that can be used to synchronize on an
>> object monitor while executing a given target method handle.
>>
>> The returned method handle behaves similar to the notional code:
>>
>>
>> R adapter(Object lock, A... a) throws Throwable {
>> synchronized (lock) {
>> return body.invokeExact(a...);
>> }
>> }
>>
>>
>> The lambda form is similar to existing ones: we box up all the arguments for
>> the body handle, call a fallback function which synchronizes and invokes the
>> body with the boxed argument, then the `Object` result is fed to an unboxing
>> handle to unbox the result if needed.
>>
>> There's a corresponding intrinsic in `InvokerBytecodeGenerator` which
>> replaces these three operations with `monitorEnter`/`monitorExit`
>> instructions, direct argument/return value forwarding without (un)boxing,
>> and the necessary exception handling which makes sure we unlock the lock
>> again in case the body throws an exception. The generated code is similar to
>> what javac generates.
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2272:
>
>> 2270: }
>> 2271:
>> 2272: private static LambdaForm makeSynchronizeForm(MethodType
>> basicType, BoundMethodHandle.SpeciesData data) {
>
> The `data` is always BMH_LLL and you are already hardcoding the fields using
> the `fieldCursor` below. I think you should drop this argument because it
> just provides a false illusion of flexibility. (Though arguably the same
> problem exists for the tableswitch form you added before)
Ok I'll drop the parameter. For `tableSwitch`, I was probably trying to avoid
having to do a lookup twice.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32817#discussion_r4004275819
