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 IIUC, the vtable is removed because all virtual calls on that class all removed either because they are dead, or they can be devirtualized to a virtual call on a subtype. As a result, is there an annotation that tells the compiler that a virtual method should not be removed? It should preserve the vtable, right? > Making the destructor virtual fails in the HS build because it seems not to > work with derived classes. That sounds confusing to me, normally it should be the opposite, are we even sure the destructors are called properly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/30771#issuecomment-4282422488
