On Oct 10, 2014, at 9:08 PM, Vladimir Ivanov <vladimir.x.iva...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
