[9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

[Vladimir Ivanov]

Paul,

Thanks for the feedback!

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/

>> http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8059877
>>
>
> Generally looks ok.
>
> - MethodHandleImpl
>
>   786              if (wrapper.unblock()) {
>   787                  // Reached invocation threshold. Replace counting/blocking wrapper with a reinvoker.
>   788                  wrapper.isActivated = false;
>
> If unblock() returns true then isActivated is already false.
Fixed.

> At the expense of another box you could use an AtomicBoolean with compareAndSet if you want to really guarantee at most one unblocking, although the box can be removed if the boolean is changed to 'int' and Unsafe is used to CAS.
I considered that, but I decided not to go that route. GuardWithTest is 
a very common combinator, so footprint overhead could be noticeable. 
There's no need to guarantee uniqueness of unblocking operation. The 
operation is idempotent, so no problems performing it multiple times. 
What I try to achieve with the flag is avoid pathological situation when 
some thread continuously updates the form.

> I dunno if strengthening the visibility of MethodHandle.form by stamping in a memory fence after the following will help
>
>   792                  wrapper.updateForm(lform);
>
> e.g. using Unsafe.fullFence.
I think the fence should be there. It won't help guarantee the update is 
visible everywhere though. But it is expected.

> Perhaps isUnblocked is a better name than isActivated since there is no need to set the initial value and it tracks the same value as that returned from unblock?
Done.

> Also while on the subject of naming perhaps consider changing MethodTypeForm.LF_DELEGATE_COUNTING to ...LF_DELEGATE_BLOCK_INLINING?
Done.

> When DONT_INLINE_THRESHOLD > 0 and DONT_INLINE_THRESHOLD == COMPILE_THRESHOLD will that trigger both compilation of a BlockInliningWrapper's form and unblocking? I guess there is some fuzziness depending on concurrent execution.
No problems expected in this scenario - COMPILE_THRESHOLD updates 
LambdaForm entry point and unblocking operates on a method handle.

> I am just wondering if there is any point compiling a BlockInliningWrapper's form if DONT_INLINE_THRESHOLD is expected to be ~ the same as COMPILE_THRESHOLD. Probably not terribly important especially if the JIT-compiler control approach replaces it.
I don't see any value in keeping BlockInliningWrapper interpreted.
It would allow to avoid LambdaForm.forceInline flag, but there should be 
a special case to skip compilation (in 
LambdaForm::checkInvocationCounter()). Moreover, if we get rid of 
LambdaForm interpreter, we will need to precompile BlockInliningWrapper 
again.

Best regards,
Vladimir Ivanov