Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28
Harold Seigel
harold.seigel at oracle.com
Tue Jan 19 20:52:27 UTC 2021
Hi Michael,
I entered bug https://bugs.openjdk.java.net/browse/JDK-8260009 for this problem.
Thank you for reporting it.
Harold
________________________________
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> on behalf of Michael Rasmussen <MRasmussen at perforce.com>
Sent: Tuesday, January 19, 2021 3:27 PM
To: hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>
Subject: Permitted Subclasses verification issue when redefining class (InstanceKlass::has_as_permitted_subclass) in jdk-16+28
Hi,
I noticed a regression in the verification of sealed classes, that I've narrowed down to happening between jdk-16+27 and jdk-16+28.
Retransforming or redefining a sealed class can lead to a JVMTI_ERROR_FAILS_VERIFICATION, with Exception <a 'java/lang/IncompatibleClassChangeError'{0x00000000feb820a0}: class autotest.TransparentRectangle cannot inherit from sealed class autotest.Rectangle> (0x00000000feb820a0), even though the class actually does that.
I've tried to investigate the reason, and from what I can tell, it boils down to the check in InstanceKlass::has_as_permitted_subclass.
In jdk-16+27, this method always seems to take the Symbol branch (_constants->tag_at(cp_index).is_klass() is false).
But for jdk-16+28, it takes the Klass branch after the classes are loaded, and from what I can tell the (k2 == k) comparison can then fail during the redefinition since the Klass stored in the _permitted_subclasses is not the same as the one being verified, as a new InstanceKlass is allocated for the stream parser.
Unfortunately, I haven't been able to produce a small self-contained test example, but I can reliably reproduce it while developing JRebel (which utilizes class retransformation), but hopefully the above is at least helpful in finding the issue and fixing it.
/Michael
This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.
More information about the hotspot-dev
mailing list