harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bu qi cheng" <buqi.ch...@gmail.com>
Subject Re: Enable the MACRO _DEBUG_CHECK_NULL_
Date Tue, 18 Nov 2008 05:50:17 GMT
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

Mime
View raw message