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

[Matthias Baesken]

On Thu, 14 Nov 2024 11:27:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> 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...

I switched from my standard gcc 11.3.0 devkit to 13.2.1; build works nicely with it and  jtreg HS :tier1 results look similar.
I still get those ugly  `warning: call to ‘vsnprintf’ declared with attribute warning: use os::vsnprintf`   [-Wattribute-warning] ;  maybe we should disable the attribute warnings for the lto build ?

One thing I maybe have to add - I currently do not build the lto build with gtest (--with-gtest was removed from my script).

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

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