RFR: 8345265: Minor improvements for LTO across all compilers [v2]

[Matthias Baesken]

On Fri, 17 Jan 2025 13:50:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> > Member
>>> 
>>> Fixing the JVM under LTO is likely to be a heavy undertaking, much more so than just unbreaking compilation and linking of the JVM (Ignoring that the JVM later crashes when the newly compiled JDK is used to build parts of itself), I'm not sure it would be feasible under the current Pull Request
>> 
>> I was able to build the OpenJDK with LTO enabled on Linux and Windows (so the new JVM does not crash in the build). I just had to not enable gtest because this is currently not compiling with LTO enabled.  I was able to run a few benchmarks with the LTO enabled JVM , but  as far as I remember a couple of HS jtreg tests fail with LTO enabled  because they have some expectations that might not (yet) work with LTO.
>> 
>> Regarding gtest, I created
>> https://bugs.openjdk.org/browse/JDK-8346987
>> 8346987: [lto] gtest build fails
>>  Do you think it would be okay to change the build so that the LTO related flags (in case lto is enabled) do not 'go'  into the gtest build ?
>
>> I was able to run a few benchmarks with the LTO enabled JVM , 
>> but as far as I remember a couple of HS jtreg tests fail with LTO enabled because they have some expectations that might not (yet) work with LTO
> 
> On Linux x86_64  (gcc 11.3 devkit) ,  when building with lto enabled, the  jdk  :tier1  jtreg  tests all worked nicely in my environment.
> The HS :tier1 jtreg tests  had  51 failures, 50 in the  serviceability/sa  area .
> Those failures (from  serviceability/sa) seem to have in common that they show such an exception 
> 
>  stderr: [Exception in thread "main" 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:78)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:926)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2230)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2200)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2071)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> or   test   serviceability/sa/TestJhsdbJstackMixed.java
> 
>  stderr: [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:1...

> @MBaesken Currently with LTO active on gcc 14 commit [e648a90](https://github.com/openjdk/jdk/commit/e648a907b31fd0d6b746d149fda2a8d5fbe26dc0) is causing serious trouble on my end by mass inlining everything, bloating the JVM to nearly 60MB in size, does HotSpot have the same size issues on your end with LTO? (--enable-jvm-feature-opt-size is off the table because the JVM should ideally be an acceptable size even without that flag, and -Os and LTO doesn't work with gcc anyway)

On my end we used gcc11 in the past and now test gcc13.  Both work nicely,  no libjvm.so bloat has been observed with lto.
Maybe there is some issue/difference with gcc14 but so far we did not test with this version.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2665762834