RFR: 8344922: Redefinition verifies the new klass when verification is disabled

David Holmes dholmes at openjdk.org
Mon Dec 9 02:11:39 UTC 2024


On Fri, 6 Dec 2024 21:34:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change only verifies redefined classes if Verification is enabled.  BytecodeVerificationRemote will be false for verification turned off.  If someone turns it off but BytecodeVerificationLocal on (which is non-sensical), the argument processing code will fix that up.  So all this needs to do is check for BytecodeVerifificationRemote for -Xverify:none (which is a deprecated option).
> 
> 
>   // Treat the odd case where local verification is enabled but remote
>   // verification is not as if both were enabled.
>   if (BytecodeVerificationLocal && !BytecodeVerificationRemote) {
>     log_info(verification)("Turning on remote verification because local verification is on");
>     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>   }
> 
> 
> Tested with runtime/verifier, jck vm and tier1-4 (in progress), and the new test case.

src/hotspot/share/classfile/verifier.cpp line 137:

> 135:   return (should_verify_class &&
> 136:     // Override parameter (return false) if -Xverify:none
> 137:     BytecodeVerificationRemote &&

Sorry but I don't understand why the correct value for `should_verify` doesn't filter through from `Verifier::should_verify_for`??? Seems to me that is the only place where we should explicitly check the verification flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22617#discussion_r1875179302


More information about the hotspot-runtime-dev mailing list