On Wed, Nov 19, 2008 at 3:20 AM, Mikhail Fursov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
