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