RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc

[Roman Kennke]

Hi Coleen,

thanks for looking at this.

I've combed the interpreter code for similar occurances, but haven't
found any.

Extra verification in cmpptr could be done but it's probably not worth.?
It'll not be a small effort...

Roman


> This looks good. Did you search for other cmpptr() to see if they should
> be cmpoop?  Wonder if you can do a negative verify_oop in cmpptr. 
> Probably not.
> 
> Lots of people look at the interpreter code, but they're on
> hotspot-runtime.
> 
> Thanks,
> Coleen
> 
> 
> On 9/27/18 4:33 PM, Roman Kennke wrote:
>> Included hotspot-runtime-dev because it's an interpreter bug, excluded
>> hotspot-compiler dev, and also here's all the links:
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8211241
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/
>>
>> It's never been quite clear to me where to put interpreter bugs.
>> hotspot/runtime in Jira and hotspot-runtime-dev on mailing lists? Is
>> that right?
>>
>> Thanks, Roman
>>
>>
>>
>>> TemplateTable::fast_aldc compares the just-loaded reference with
>>> Universe::the_null_sentinel. If it really is that null-sentinel, we may
>>> get a false negative (with GCs like Shenandoah that allow both
>>> from-space and to-space copies of an object to be around), and thus skip
>>> NULL-ing the ref. In other words, it would allow to get
>>> the-null-sentinel out into the wild as oop which can cause subtle and
>>> not-so-subtle bugs.
>>>
>>> Fix is easy, call cmpoop() which re-routes through GC-interface for GCs
>>> that need it:
>>>
>>> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/
>>>
>>> Testing: hotspot/jtreg:tier1
>>>
>>> Ok?
>>>
>>> Roman
>>>
>