RFR(XS): 8144852: Corrupted oop in nmethod

[Ioi Lam]

Currently non_oop_word is used only in the nmethod code. If this value 
is assigned to an oop or a metadata* elsewhere we would probably see 
massive crashes. Adding non_oop_word to oopDesc::print_*_on would imply 
that it's OK to assign this value in a more general context, which is 
not true.

So I would suggest keeping knowledge of non_oop_word inside nmethod for 
now, and we can revisit this if other places start to use non_oop_word.

Thanks
- Ioi

On 12/16/15 12:41 PM, Dean Long wrote:
> Ping.
>
> Could runtime folks please comment on Vladimir's suggestion to have 
> oopDesc::print_*_on and
> Metadata::print_*_maybe_null support Universe::non_oop_word() values 
> without crashing, or if I should keep this change in nmethod only.
>
> thanks,
>
> dl
>
> On 12/11/2015 11:18 AM, Dean Long wrote:
>> [adding hotspot-runtime-dev]
>>
>> On 12/11/2015 3:49 AM, Vladimir Ivanov wrote:
>>> Dean, thanks for taking care of it.
>>>
>>> Can oopDesc::print_value_on and print_value_on_maybe_null be 
>>> enhanced instead to handle non_oop_word case (in addition to NULL 
>>> case)?
>>>
>>
>> I thought of that, but didn't want to add 
>> print_value_on_maybe_null_or_non_oop :-)
>>
>> If you feel strongly about that, then I should probably get input 
>> from runtime too, since I think they own that code.
>>
>>> Also, the following is slightly misleading since metadata pointers 
>>> aren't oops:
>>>  void nmethod::print_recorded_metadata() {
>>> +    if (m == (Metadata*)Universe::non_oop_word()) {
>>> +      tty->print("non-oop word");
>>>
>>
>> Would "non-metadata word" be better?
>>
>> dl
>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 12/11/15 6:36 AM, Dean Long wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8144852
>>>> http://cr.openjdk.java.net/~dlong//8144852/webrev/
>>>>
>>>> The fix for [1] introduced new functions nmethod::print_recorded_oops
>>>> and nmethod::print_recorded_metadata that print all oop and metadata
>>>> values in an nmethod.  Currently NULL values are handled OK, but
>>>> Universe::non_oop_word values cause a crash.
>>>>
>>>> (This bug is marked confidential because it was reported against 
>>>> one of
>>>> our closed ports.)
>>>>
>>>> dl
>>>>
>>>> [1]     JDK-8072008: Emit direct call instead of linkTo* for recursive
>>>> indy/MH.invoke* calls
>>
>