RFR: 8212921: Relax code cache oop verification in ZGC

[Per Liden]

Ok, thanks for reviewing, Erik.

/Per

On 10/31/2018 03:19 PM, Erik Österlund wrote:
> Hi Per,
> 
> I prefer your approach - it allows more verification which is good. 
> Looks good. I'll reassign this to you.
> 
> Thanks,
> /Erik
> 
> On 2018-10-31 15:10, Per Liden wrote:
>> On 10/25/2018 03:18 PM, Erik Österlund wrote:
>>> Hi,
>>>
>>> With concurrent class unloading, the normal state of affairs for ZGC 
>>> is that nmethods have messed up oops in all GC safepoints, and fix 
>>> them up during concurrent phases. Therefore, Universe::verify needs 
>>> to relax the assumption that oops are okay for ZGC.
>>>
>>> Note that during Universe::verify, the oops in the nmethods were 
>>> redundantly verified. Once by walking the oops in the code cache, and 
>>> once when calling nmethod::verify(), which did the same verification 
>>> again. I removed the latter.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8212921/webrev.00/
>>
>> I discussed this with Erik off-line. Instead of adjusting the 
>> verification code to do what ZGC needs, we could instead move ZGC's 
>> verification to after resurrection is unblocked. At this time, all 
>> oops we find will be good and no special nmethod verification will be 
>> needed.
>>
>> Here's a webrev to adjust to that model:
>>
>> http://cr.openjdk.java.net/~pliden/8212921/webrev.0
>>
>> I also noticed that we could remove some boilerplate code by fusing 
>> ZVerifyRootOopClosure and ZVerifyHeapOopClosure into a single 
>> ZVerifyOopClosure, which I did.
>>
>> I still agree that the current double verification of nmethod oops 
>> seems completely unnecessary, but it's harmless so that can be handled 
>> by a separate RFE.
>>
>> cheers,
>> Per
>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8212921
>>>
>>> Thanks,
>>> /Erik
>