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 It's a bit unfortunate that the virtual destructor trick doesn't work, I was just about to suggest it since that's what Kim proposed in the Windows RTTI Pull Request. There is technically another way, to use the optimize pragma with the string no-devirtualize, but besides the fact that I didn't test it, it's also a bit too heavy since that disables all optimizations related to vtables and doesn't just keep the vtable, while we still want the optimizations, we only want the vtable to be kept without disabling optimization, since I _think_ Metadata is a performance critical class. In the meantime I'll keep testing to see if there are any clean ways to keep the vtable. I think it's a shame that none of the compilers have something like [[gnu::vtable(true)]] that you can use to force the vtable to be kept though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30771#issuecomment-4280464431
