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

[Matthias Baesken]

On Thu, 14 Nov 2024 09:21:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> And not under the rubric of a warnings fix.
>> 
>> Maybe the title is a bit misleading, it is more about a build fix (lto build did not work for me with gcc 11.3.0; with this fix it works).
>> If the lot stuff is broken and there is no intent to fix it, we might consider removing it (but fixing it would probably be better).
>
> 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).

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

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