RFR: 8330606: Redefinition doesn't but should verify the new klass [v3]

[Coleen Phillimore]

On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path.
>> 
>> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class".  By default this parameter follows the -Xverify setting.  For redefinition, this is passed as true.   The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do.  If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes.
>> 
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification.

Thanks for answering David.  The new class should get a VerifyError not a ClassFormatError - the bytecodes were incorrect, as detected by the verifier.  It's not missing a code attribute but the code is truncated as reported with -Xlog:exceptions:


[0.339s][info][exceptions] Exception <a 'java/lang/VerifyError'{0x00000007ff8850c8}: Control flow falls through code end
[                        ] Exception Details:
[                        ]   Location:
[                        ]     java/lang/VerifyError.<init>()V @0: <invalid>
[                        ]   Reason:
[                        ]     Error exists in the bytecode
[                        ]   Bytecode:
[                        ]     0000000:
[                        ] > (0x00000007ff8850c8)
[                        ] thrown [/scratch/cphillim/hg/jdk-ci-pd/open/src/hotspot/share/classfile/verifier.cpp, line 293]
[                        ] for thread 0x000075ea2cbbe260


In the test the methods are here just don't have anything in them:


        {
            methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "<init>", "()V", null, null);
            methodVisitor.visitCode();
            methodVisitor.visitEnd();
        }

        {
            methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "<init>", "(Ljava/lang/String;)V", null, null);
            methodVisitor.visitCode();
            classWriter.visitEnd();
        }


So VerifyError is the right exception.  It might be that you need to add some nop() bytecode or something to generate the code attribute?

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

PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2640709606