RFR: 8376295: "assert(BytecodeVerificationRemote) failed: Should not be here" when running class redefinition test with -XX:-BytecodeVerificationRemote

Coleen Phillimore coleenp at openjdk.org
Mon Feb 23 22:58:14 UTC 2026


On Thu, 29 Jan 2026 12:04:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The  
>> `_klass->should_verify_class()`
>>  is false when class is redefined. 
>> The '_klass' in fresh "scratch class".  So the  `bool Verifier::verify(InstanceKlass* klass, bool should_verify_class)`  is called for "scratch_class"  with  `should_verify_class = true`. 
>> The `should_verify_class = true` is needed because it is not possible to just call 
>> `scratch_class->set_should_verify_class(true);` 
>> in the safepoint. 
>> 
>> The stacktrace:
>>  ClassVerifier::verify_class(JavaThread* (verifier.cpp:625)
>> Verifier::verify(InstanceKlass*, bool`should_verify_class = true`  , JavaThread*) (verifier.cpp:223)
>>  VM_RedefineClasses::load_new_class_versions()  (jvmtiRedefineClasses.cpp:1459)
>>  VM_RedefineClasses::doit_prologue() (jvmtiRedefineClasses.cpp:1334)
>> VMThread::execute(VM_Operation*) (vmThread.cpp:541)
>> JvmtiEnv::RedefineClasses(int, jvmtiClassDefinition const*)+0x18a (jvmtiEnv.cpp:505)
>
> Okay that is a pity. Thanks for explaining.

https://bugs.openjdk.org/browse/JDK-8344922 We should always verify the redefined class even when BytecodeVerificationRemote is off.  We decided that and have a release note.

I thought we had a test for this also.  If not, we should have a test for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29476#discussion_r2843483971


More information about the serviceability-dev mailing list