RFR: JDK-8237780: Shenandoah: More reliable nmethod verification

Roman Kennke rkennke at redhat.com
Fri Feb 14 19:29:34 UTC 2020


This is another fallout from the Lucene debugging sessions :-)

Our nmethod verification has a number of problems:

- the assert(oops->length() == oop_count(), "Must match") is too too
strict. Weirdly, while we are registering an nmethod in one thread
(under CodeCache_lock), another thread can already patch the same
nmethod (under Patching_lock). Which can throw off the countings.
- We need to skip Universe::non_oop_word() because that what standard
oop iterator would do too.

It's fixed by:
1. counting actual oops, skipping Universe::non_oop_word() instead of
comparing with oop_count()
2. relaxing the assert from == to >=

I've also added a sanity check:

+    assert(nm == data->nm(), "must be same nmethod");

I've also left in some debug-output but under #ifdef ASSERT_DISABLED. I
found that very useful and wouldn't want to throw it away.

All of this has proven to be useful (if only to exclude the possibility
that we mess up something in handling Nmethods).

Bug:
https://bugs.openjdk.java.net/browse/JDK-8237780
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.00/

Testing: provided testcase passes now (failed before).
hotspot_gc_shenandoah is fine

Can I please get a review?

Thanks,
Roman



More information about the hotspot-gc-dev mailing list