RFR: 8343698: Linux x86_64 lto build gives a lot of warnings and fails lto-wrapper: fatal error: make returned 2 exit status

[Kim Barrett]

On Thu, 14 Nov 2024 10:02:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I would hope that LTO won't be removed. I plan to try making it viable, and I also use it downstream on Windows. I'm having trouble downgrading my gcc package on WSL to reproduce the warning, so might take me some time to find a better fix
>
>> Hmmm ... I thought we had LTO enabled in the past for Java SE Embedded ...
> 
> Hi Julian / David,  I  started the HS :tier1 tests with the  lto-enabled JVM (linuxx86_64).
> Most tests work, but I get a number of errors too, mostly (but not only) in the  serviceability/sa   area.
> A lot of tests fail with 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.Oop.getKlassForOopHandle(Oop.java:224)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:180)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.oops.VMOopHandle.resolve(VMOopHandle.java:61)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getThreadObj(JavaThread.java:365)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:438)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:80)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:79)
> 	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$32.doit(CommandProcessor.java:1229)
> 	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)
> 
> 
> So I would say that the lto-enabled JVM is not completely broken but has some issues here and there (revealed by the jtreg tests).

My experience is quite different.  As I've said previously, I'm not getting anywhere near through a build
with gcc13.2.  As far as I can tell, building with LTO is quite badly broken.  It's bad enough, and other
runtime issues seem nasty enough to me, that I'm giving up on following this.  We have gotten a couple
of good bug fixes out of it, but for the rest...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22069#discussion_r1842061125