CR 6826736/6-pool *Escalated* Updated, P3 hotspot/garbage_coll CMS: core dump with -XX:+UseCompressedOops

[Vladimir Kozlov]

I spoke too soon.

This behavior is intentional for performance.
On sparc we generate code which produce live oop with
narrow_oop_base_addr value when narrow oop is NULL :

     Load_narrow_oop memory, narrow_oop_reg
     decode_not_null narrow_oop_reg, base_reg
     // The problem is base_reg may be referenced by
     // debug info before the next implicit check:
     Load [base_reg + offset], val_reg
     NullCheck base_reg

Also decode_not_null may flow above NULL check since
it does not have control edge. I think, it is fine since
all code users of a decoded value are below NULL check
(or it has implicit NULL check). Except a debug info.

The implicit NULL exception code checks for narrow_oop_base_addr value.
I think we have to fix deoptimization code and GC also to check
for such oops values and convert them to NULL.
I will work on it.

The alternative is disable narrow oop implicit NULL check on sparc
and performance lost on all platforms.

Thanks,
Vladimir

Vladimir Kozlov wrote:
> Yahoo!!! I built a small test case which shows the problem:
> GCM placed decode_not_null node above implicit null check.
> 
> Vladimir
> 
> Y. Srinivas Ramakrishna wrote:
>> Thanks, Vladimir; no hurry!
>>
>> -- ramki
>>
>> Vladimir Kozlov wrote:
>>> The fix for 6851282 did NOT fix the 6826736 problem.
>>>
>>> Yesterday I found the cause of 6826736 and I am trying to
>>> prepare the fix about which I talked with Ramki.
>>> Now I can reproduce the problem myself after
>>> adding dynamic 0 assert check into decode mach node.
>>> Give me few days.
>>>
>>> thanks,
>>> Vladimir
>>>
>>> Y. Srinivas Ramakrishna wrote:
>>>>
>>>> Hi Poonam, Vladimir --
>>>>
>>>> Poonam.Bajaj at Sun.COM wrote:
>>>>>                         Sun Confidential: Internal only
>>>>>
>>>>> *Synopsis*: CMS: core dump with -XX:+UseCompressedOops
>>>>>
>>>>>
>>>>> r12 contains oop being accessed :    0xfffffd7fe85ff000
>>>>>
>>>>> And it is 4K (0xfffffd7fe8600000 - 0xfffffd7fe85ff000 = 0x1000) 
>>>>> below the start of eden space.
>>>>>
>>>>> Fix for 6851282 has been integrated. I am going to test with this 
>>>>> fix and see if it resolves this crash too.
>>>>>
>>>>> *** (#2 of 2): 2009-07-17 10:57:37 GMT+00:00 poonam.bajaj at sun.com
>>>>> *** Last Edit: 2009-07-17 11:07:54 GMT+00:00 poonam.bajaj at sun.com
>>>>>   
>>>> Thanks Poonam.  Vladimir stopped by yesterday to ask whether I could 
>>>> test with the fix he had
>>>> for the problem and that he would send me the fix. I am guessing he 
>>>> was referring to the fix he
>>>> put back for 6851282, but i was not 100% sure because he was working 
>>>> on, i think, an
>>>> additional issue as well. Anyway, I am cc'ing Vladimir to check with 
>>>> him that this was indeed
>>>> the fix with which he wanted us to run/verify.
>>>>
>>>> Vladimir?
>>>>
>>>> thanks!
>>>> -- ramki
>>>>> ...
>>>>>
>>>>> === *Escalations* 
>>>>> ============================================================
>>>>>
>>>>>         Escalation Number    1-26544441
>>>>>         Escalation Date      2009-07-14 10:46:06 GMT+00:00
>>>>>         Status               In Progress
>>>>>         Management Alert             Customer Advocate    apollo
>>>>>         Escalation Engineer  poonam.bajaj at sun.com