harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: Enable the MACRO _DEBUG_CHECK_NULL_
Date Wed, 19 Nov 2008 00:19:56 GMT
On Wed, Nov 19, 2008 at 3:20 AM, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> 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.

Agreed. We can't simply work around the issue by saying: hey I have
double-checks, it is safe anyway, although one check is enough.

Thanks,
xiaofeng

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



-- 
http://xiao-feng.blogspot.com

Mime
View raw message