On Thu, 14 Nov 2024 09:21:06 GMT, Julian Waters <[email protected]> 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
