On Thu, 14 Nov 2024 10:02:44 GMT, Matthias Baesken <mbaes...@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
