On Mon, 20 Apr 2026 10:44:36 GMT, Matthias Baesken <[email protected]> wrote:
>> When building hotspot on linuxx86_64/gcc with LTO enabled >> (--enable-jvm-feature-link-time-opt), we get various test errors in the >> serviceability/sa area. >> Example serviceability/sa/CDSJMapClstats.java >> >> >> finding class loader instances ..java.lang.InternalError: Metadata does not >> appear to be polymorphic >> at >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:77) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) >> >> >> Seems we have to avoid elimination of the Metadata vtable ; this can be >> achieved by linker flags or by modifying class Metadata. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Remove uncommented linker setting from JvmFeatures.gmk vtables can be shared if identical. I think the issue with #12743 is that NotificationThread is an override of JavaThread, but provides no additional virtual methods, so the NotificationThread vtable was stripped and instances of NotificationThread just point to the JavaThread vtable. This confuses SA, which needs to know about all JavaThread subtypes. Adding a virtual method to NotificationThread fixed this. The issue with Metadata seems to be a bit different. I think the problem is that it is an abstract class. Since you can't have an instance of an abstract class, you don't need its vtable, and it gets stripped. However, SA does need it. The references comes from the following SA code: metadataConstructor.addMapping("Metadata", Metadata.class); It's not clear to me why it needs this mapping. You might want to try to remove it and see if SA still works. Regarding the proposed fix, it's not clear to me how adding a constructor forces the vtable to be retained. Regarding enabling the proposed fix for PRODUCT builds, that means adding the _valid field (and maybe the is_valid() method) to PRODUCT builds. This field will take up space in every instance of every Metadata subtype (every class, field, method, and constant pool currently loaded). ------------- PR Comment: https://git.openjdk.org/jdk/pull/30771#issuecomment-4282649692
