On Thu, 30 Apr 2026 14:54:05 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:
> 
>   use gnu::retain

It's ignoring the retain attribute explicitly and failing the compile now, 
which is strange, given that in my own tests it never did that. At this point I 
feel like the linker flag might be the better option, despite the flag looking 
like a hack, all the source code changes we could try seem to be messier than 
the flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/30771#issuecomment-4358244319

Reply via email to