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.
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
More information about the hotspot-gc-dev
mailing list