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

[Paul Sandoz]

On Oct 10, 2014, at 9:08 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 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.

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 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.


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? 

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


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. 

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.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141013/de4d742b/signature.asc>