On Thu, 14 Nov 2024 11:27:25 GMT, Kim Barrett <kbarr...@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
