RFR: 8140584: nmethod::oops_do_marking_epilogue always runs verification code (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Oct 30 08:44:24 UTC 2015

On 10/29/15 11:52 PM, Stefan Karlsson wrote:

Hi Vladimir,

On 2015-10-27 16:22, Vladimir Kozlov wrote: CodeCache::verifyoops() also calls it unguarded.

I think for complete solution nmethod::verifyooprelocations() and called from it oopRelocation::verifyooprelocation(), verifyvalue(), constverifydatavalue() and pdverifydatavalue() should be declared and defined in debug build only. I see what you're saying, but I'm unsure that this is really what we want to do. CodeCache::verifyoops is called from the Universe::verify, that can be enabled in product builds by setting -XX:+UnlockDiagnosticVMOptions and -XX:+VerifyBeforeGC and/or -XX:+VerifyAfterGC. Maybe we want to change the relocation code to use guarantees instead of asserts? So that we can get verification of the relocation code in product builds?

Yes, I think it is good suggestion (asserts -> guarantees or fatals) in addition to webrev.01.

Thanks, Vladimir

Thanks, StefanK

Thanks, Vladimir On 10/27/15 7:44 PM, Stefan Karlsson wrote: Hi,

Please review this patch to remove some unnecessary verification code from our product builds. Today, CodeCache::gcepilogue() guards the call to nmethod::verifyooprelocations with DEBUGONLY, while nmethod::oopsdomarkingepilogue doesn't. Since nmethod::verifyooprelocations uses asserts when verifying the relocations, this is just wasted cycles in product builds. This patch adds DEBUGONLY to nmethod::oopsdomarkingepilogue. http://cr.openjdk.java.net/~stefank/8140584/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8140584 Thanks, StefanK

More information about the hotspot-dev mailing list