RFR: 8212921: Relax code cache oop verification in ZGC

Erik Österlund erik.osterlund at oracle.com
Wed Oct 31 14:19:15 UTC 2018

Hi Per,

I prefer your approach - it allows more verification which is good. 
Looks good. I'll reassign this to you.


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

More information about the hotspot-gc-dev mailing list