On Fri, 10 Jan 2025 10:42:50 GMT, Kim Barrett <[email protected]> wrote:
>>> Hi, the workaround 'disable lto in g1ParScanThreadState because of special >>> inlining/flattening used there' is removed , why this works now ? >> >> The issue there was the `-Wattribute-warning` warnings that were being >> generated. But this change is suppressing >> those warnings in the LTO link: >> https://github.com/openjdk/jdk/blame/9d05cb8eff344fea3c6b9a9686b728ec53963978/make/hotspot/lib/JvmFeatures.gmk#L176C11-L176C11 >> Note that won't work with the new portable forbidding mechanism based on >> `deprecated` attributes. >> >> I'm trying this new version, and I still get a few other warnings and then >> seem to have a process hang in lto1-ltrans. >> The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped >> in that respect. > >> I'm trying this new version, and I still get a few other warnings and then >> seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to >> `-flto=$(JOBS)` doesn't seem to have helped in that respect. > > Turns out I didn't wait long enough. It does terminate after about 40 > minutes, though not successfully. Instead the > build crashes with a failed assert: > > # Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), > pid=4017588, tid=4017620 > # assert(_thread->is_in_live_stack((address)this)) failed: not on stack? > > I've not tried to debug this. Maybe it's a consequence of one of those > problems of bypassing an intentional implicit > noinline in our code (by ensuring a function definition is in a different TU > from all callers), with LTO breaking that. > Or maybe LTO is breaking us in some other way (such as taking advantage of > no-UB constraints that aren't found > by normal compilation). After trying and failing and trying and failing countless hours and days... I admit I'm nowhere close to solving this problem. I just can't figure out what the slow paths and external methods not local to the g1ParScanThreadState.cpp source file are. Every attempt at using a tool to discern this has failed catastrophically, and the call hierarchy is enormous, meaning manually trying to do this myself is out of the question. @kimbarrett if I could ask, what are the slow paths that should not be inlined, and what are the methods that are not local to the source file in question? If I just knew what to look at, maybe I could begin to start tackling this problem properly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3362079047
