RFR(XS): 8144852: Corrupted oop in nmethod

[Dean Long]

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
>