harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: Enable the MACRO _DEBUG_CHECK_NULL_
Date Tue, 18 Nov 2008 19:20:57 GMT
Hi Buqi,

I think the issue with not-inlined monenter must be fixed - if monenter is
"hot" it must be replaced with inlined magic code. Are you sure that
monenter inst is "hot" in the code you use?

The null check for monenter must be done in Java code at least once. If
there is another nullcheck before the monenter -> the monenters one must be
eliminated. If it isn'tt - it's a bug that must be fixed.


On Tue, Nov 18, 2008 at 11:50 AM, bu qi cheng <buqi.cheng@gmail.com> wrote:

> Hi Mikhail:
>
>     Thanks for informatoin! I am sorry that I made a mistake in the
> command line. The -Xem:client should be -Xem:server. I copied a wrong
> command line. With your help, I found the magic code in
> threadhelper.java:
>    @Inline
>    static void monitorExit(Object obj) {
>        Address lockWordPtr =
> ObjectReference.fromObject(obj).toAddress().plus(LOCK_WORD_OFFSET);
>        int lockword = lockWordPtr.loadInt();
>        if (((lockword & (FAT_LOCK_MASK|RECURSION_MASK)))!=0) {
>            if ((lockword & FAT_LOCK_MASK)==0) {
>                lockword-=RECURSION_INC_IN_PLACE;
>                lockWordPtr.store(lockword);
>                return;
>            }
>        } else {
>            lockword&=~HI_BITS;
>            lockWordPtr.store(lockword);
>            return;
>        }
>        VMHelper.monitorExit(obj);
>    }
>
>
> However, in the test case in last email, from the SD2 IR, we can not
> find that the magic is called. So the same bug will happen. Of course
> if add back the null pointer check in rth_get_lil_monitor_enter(), the
> bug will disappear. However, the optimization chance will lost.
>
> Another problem is that in the inliner.cpp, in function
> connectRegion() we can find code like:
>    Inst* tauNullCheckInst = tauNullChecked->getInst();
>    if(tauNullCheckInst->getOpcode() == Op_TauCheckNull) {
>        tauNullCheckInst->setDefArgModifier(NonNullThisArg);
>    }
>
> I think this means that if the inline done, the chknull for the
> argument will be un-optimizable. If the magic is called, no error, and
> no optimization at the same time. Am I right?
>
> Thanks!
>
> Buqi
>
>
>
> Thanks!
>
> Buqi
>



-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message