JDK-8343698 : Linux x86_64 lto build gives a lot of warnings and fails lto-wrapper: fatal error: make returned 2 exit status
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 24
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2024-11-06
  • Updated: 2025-02-28
  • Resolved: 2024-11-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b26Fixed
Related Reports
Relates :  
JDK-8344080 - Return type mismatch for jfr_unregister_stack_filter
Relates :  
JDK-8345265 - Minor improvements for LTO across all compilers
Relates :  
JDK-8250597 - G1: Improve inlining around trim_queue
Relates :  
JDK-8344161 - Argument type mismatch for jfr_type_id
Description
When trying LTO  (configure flag --enable-jvm-feature-link-time-opt=yes)  on Linux x86_64, gcc 11.3.0  we run into a lot of warnings and finally into this error :

 .. tons of free and malloc related warnings ...

    inlined from 'pop_segment' at src/hotspot/share/utilities/stack.inline.hpp:188:9,
    inlined from 'pop' at src/hotspot/share/utilities/stack.inline.hpp:84:30,
    inlined from 'pop_overflow' at src/hotspot/share/gc/shared/taskqueue.inline.hpp:231:28,
    inlined from 'trim_queue_to_threshold' at src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:328:37:
src/hotspot/share/runtime/os.cpp:666:3: warning: call to 'malloc' declared with attribute warning: use os::malloc [-Wattribute-warning]
src/hotspot/share/runtime/os.cpp:666:3: warning: call to 'malloc' declared with attribute warning: use os::malloc [-Wattribute-warning]
In function 'malloc',
    inlined from 'malloc' at src/hotspot/share/runtime/os.cpp:637:0,
    inlined from 'AllocateHeap' at src/hotspot/share/memory/allocation.cpp:42:31,
    inlined from 'new_entry' at src/hotspot/share/nmt/mallocSiteTable.cpp:181:25,
    inlined from 'lookup_or_add' at src/hotspot/share/nmt/mallocSiteTable.cpp:122:48,
    inlined from 'allocation_at' at src/hotspot/share/nmt/mallocSiteTable.hpp:151:37,
    inlined from 'record_malloc' at src/hotspot/share/nmt/mallocTracker.cpp:179:35,
    inlined from 'record_malloc' at src/hotspot/share/nmt/memTracker.hpp:81:42,
    inlined from 'realloc' at src/hotspot/share/runtime/os.cpp:746:58,
    inlined from 'ReallocateHeap' at src/hotspot/share/memory/allocation.cpp:59:32,
    inlined from 'grow' at src/hotspot/share/utilities/ostream.cpp:377:15,
    inlined from 'write' at src/hotspot/share/utilities/ostream.cpp:400:11,
    inlined from 'write' at src/hotspot/share/utilities/ostream.cpp:382:0,
    inlined from 'put' at src/hotspot/share/utilities/ostream.cpp:212:8,
    inlined from 'print_ascii_form' at src/hotspot/share/runtime/os.cpp:965:19,
    inlined from 'print_hex_location' at src/hotspot/share/runtime/os.cpp:1008:21,
    inlined from 'print_hex_dump' at src/hotspot/share/runtime/os.cpp:1050:23,
    inlined from 'print_hex_dump' at src/hotspot/share/runtime/os.hpp:869:19,
    inlined from 'print_block_on_error' at src/hotspot/share/nmt/mallocHeader.cpp:64:23,
    inlined from 'resolve_checked_impl' at src/hotspot/share/nmt/mallocHeader.inline.hpp:106:41,
    inlined from 'resolve_checked' at src/hotspot/share/nmt/mallocHeader.inline.hpp:113:66,
    inlined from 'record_free_block' at src/hotspot/share/nmt/mallocTracker.cpp:206:55,
    inlined from 'record_free' at src/hotspot/share/nmt/memTracker.hpp:93:44,
    inlined from 'free' at src/hotspot/share/runtime/os.cpp:787:54,
    inlined from 'free' at src/hotspot/share/runtime/os.cpp:773:0,
    inlined from 'FreeHeap' at src/hotspot/share/memory/allocation.cpp:68:11,
    inlined from 'free' at src/hotspot/share/utilities/stack.inline.hpp:148:0,
    inlined from 'pop_segment' at src/hotspot/share/utilities/stack.inline.hpp:188:9,
    inlined from 'pop' at src/hotspot/share/utilities/stack.inline.hpp:84:30,
    inlined from 'pop_overflow' at src/hotspot/share/gc/shared/taskqueue.inline.hpp:231:28,
    inlined from 'trim_queue_to_threshold' at src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:328:37:
src/hotspot/share/runtime/os.cpp:666:3: warning: call to 'malloc' declared with attribute warning: use os::malloc [-Wattribute-warning]
src/hotspot/share/runtime/os.cpp:666:3: warning: call to 'malloc' declared with attribute warning: use os::malloc [-Wattribute-warning]
In function 'malloc',
    inlined from 'malloc' at src/hotspot/share/runtime/os.cpp:637:0,
    inlined from 'malloc' at src/hotspot/share/runtime/os.cpp:634:20,
    inlined from 'do_os_malloc' at src/hotspot/share/nmt/nmtPreInit.cpp:202:20,
    inlined from 'handle_realloc' at src/hotspot/share/nmt/nmtPreInit.hpp:325:37,
    inlined from 'realloc' at src/hotspot/share/runtime/os.cpp:691:33,
    inlined from 'ReallocateHeap' at src/hotspot/share/memory/allocation.cpp:59:32,
    inlined from 'grow' at src/hotspot/share/utilities/ostream.cpp:377:15,
    inlined from 'write' at src/hotspot/share/utilities/ostream.cpp:400:11,
    inlined from 'write' at src/hotspot/share/utilities/ostream.cpp:382:0,
    inlined from 'put' at src/hotspot/share/utilities/ostream.cpp:212:8,
    inlined from 'print_ascii_form' at src/hotspot/share/runtime/os.cpp:965:19,
    inlined from 'print_hex_location' at src/hotspot/share/runtime/os.cpp:1008:21,
    inlined from 'print_hex_dump' at src/hotspot/share/runtime/os.cpp:1050:23,
    inlined from 'print_hex_dump' at src/hotspot/share/runtime/os.hpp:869:19,
    inlined from 'print_block_on_error' at src/hotspot/share/nmt/mallocHeader.cpp:64:23,
    inlined from 'resolve_checked_impl' at src/hotspot/share/nmt/mallocHeader.inline.hpp:106:41,
    inlined from 'resolve_checked' at src/hotspot/share/nmt/mallocHeader.inline.hpp:113:66,
    inlined from 'record_free_block' at src/hotspot/share/nmt/mallocTracker.cpp:206:55,
    inlined from 'record_free' at src/hotspot/share/nmt/memTracker.hpp:93:44,
    inlined from 'free' at src/hotspot/share/runtime/os.cpp:787:54,
    inlined from 'free' at src/hotspot/share/runtime/os.cpp:773:0,
    inlined from 'FreeHeap' at src/hotspot/share/memory/allocation.cpp:68:11,
    inlined from 'free' at src/hotspot/share/utilities/stack.inline.hpp:148:0,
    inlined from 'pop_segment' at src/hotspot/share/utilities/stack.inline.hpp:188:9,
    inlined from 'pop' at src/hotspot/share/utilities/stack.inline.hpp:84:30,
    inlined from 'pop_overflow' at src/hotspot/share/gc/shared/taskqueue.inline.hpp:231:28,
    inlined from 'trim_queue_to_threshold' at src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:328:37:
src/hotspot/share/runtime/os.cpp:666:3: warning: call to 'malloc' declared with attribute warning: use os::malloc [-Wattribute-warning]
g++: fatal error: Killed signal terminated program lto1
compilation terminated.
make[4]: *** [/tmp/cc6nPei6.ltrans63.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs....
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp: In member function 'trim_queue_to_threshold':
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:325:6: note: variable tracking size limit exceeded with '-fvar-tracking-assignments', retrying without
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp:325:6: note: variable tracking size limit exceeded
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/tools/devkits/x86_64-linux-gnu-to-x86_64-linux-gnu-fedora27-gcc11.3.0/bin/../lib/gcc/x86_64-linux-gnu/11.3.0/../../../../x86_64-linux-gnu/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
+ exitcode=1
Comments
> The other is that LTO seems to be applying flattening even across translation units. > I'm wondering why these problems didn't show up when the current LTO options were being added, since the flattening was already in use by then. Is some of this because of the compiler version? This strangely seems to be a unique problem for gcc 14 only. Due to the methods being marked flatten, the mass inlining across compilation units explodes the JVM's size to an unacceptable 58MB. This might seem like it would be a problem for all gcc in general, but weirdly, back when I was using gcc 13 and below, this never happened, and the JVM's size was an acceptable 20-25MB. Matthias can corroborate this as well, as he reports that the JVM as compiled by gcc 11 and gcc 13 does not have any anomalous size increases compared to without having LTO. This leads me to believe that something changed in gcc 14 that makes it inline into methods marked as flatten far more aggressively than it used to in versions of gcc prior to 14
28-02-2025
Changeset: 9576546b Branch: master Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2024-11-25 07:57:13 +0000 URL: https://git.openjdk.org/jdk/commit/9576546b9c0f22b0784c4f845f2694050cae2f16
25-11-2024
I got much further after figuring out that our (Oracle's) devkit doesn't have the lto plugin in the right place, and working around that. No more undefined references! Still a few warnings, which need to be investigated. But a failed assert during the build, that looks like the kind of problem [~jwaters] was referring to: # Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=1567748, tid=1567761 # assert(_thread->is_in_live_stack((address)this)) failed: not on stack? A release build completed successfully, other than the same warnings. I'll look into those in a bit. Oh, and this was with FORBID_C_FUNCTIONS disabled for LTO bulids, which I'm still not thrilled about. I particularly worry that if we get LTO builds working well that we'll start using them as the default, and the FORBID_C_FUNCTIONS feature will get lost.
15-11-2024
I also noticed that LTO is being applied to gtest code. Maybe we shouldn't do that? Maybe there should be an RFE for that?
14-11-2024
This part: "variable tracking size limit exceeded with '-fvar-tracking-assignments'" has been seen before, and is the reason for MAYBE_INLINE_EVACUATION in g1ParScanThreadState.cpp. Fastdebug builds were exploding in size because of the flattening, so in fastdebug builds we cut off some of the flattening via NOINLINE.
14-11-2024
An interesting data point. I NOINLINE'd os::malloc and os::free, and that eliminated all of the -Wattribute-warning's. It's a little surprising to me that only NOINLINE'ing those functions was sufficient. Maybe the flattening is somehow driving LTO deeper, and those are the only forbidden functions reachable from the flattened paths? And the extra NOINLINE's block that.
14-11-2024
I think the real problem is that LTO is honoring the attribute-warning but not honoring the pragmas to suppress that warning. I can't think of a good solution to that. Maybe this is a gcc bug? An imperfect workaround would be to make FORBID_C_FUNTION a nop when building with LTO. Note that I still get a few warnings when building with gcc13.2 with LTO and with FORBID_C_FUNCTION disabled. Also a ton of undefined reference errors.
14-11-2024
Moving to runtime since the macros that are not honored are not gc related.
14-11-2024
I've filed another ODR violation issue turned up by this work: https://bugs.openjdk.org/browse/JDK-8344161
14-11-2024
> I also noticed that LTO is being applied to gtest code. Maybe we shouldn't do that? Maybe there should be an RFE for that? I can open a JBS issue for this, but what would be your argument to avoid lto in the gtest code ? Maybe we could argue that it is too much overhead. On the other hand, the lto options are only set for libjvm (JVM_CFLAGS_FEATURES) but not for other native libs. That surprised me a bit too.
14-11-2024
Using gcc13.2, commenting out the definition of ATTRIBUTE_FLATTEN in globalDefinitions_gcc.hpp does reduce the number of warnings substantially (~200 vs ~1400), but does not eliminate them. Most, but not all, of the warnings are -Wattribute-warning. Nor does the build complete. Depending on flattening being enabled/disabled and fastdebug vs release I get different failures. Tons of undefined references. An ODR violation, where we have a mismatch on the return type in the declaration and definition of jfr_unregister_stack_filter. (New bug for the ODR violation: JDK-8344080)
13-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22069 Date: 2024-11-13 12:17:07 +0000
13-11-2024
> An ODR violation, where we have a mismatch on the return type in the declaration and definition of jfr_unregister_stack_filter. (New bug for the ODR violation: JDK-8344080) Hi [~kbarrett] thanks for filing that one, I saw this too when building the lto-build with our gcc 11.3.0 devkit. >Nor does the build complete. Depending on flattening being enabled/disabled and fastdebug vs release I get different failures. >Tons of undefined references. With gcc 11.3.0 the lto enabled build works fine when getting rid of the ATTRIBUTE_FLATTEN stuff in g1ParScanThreadState.cpp (opt build). Regarding > I'm wondering why these problems didn't show up when the current LTO options were being added, since the flattening was already in use by then. Is some of this because of the compiler version? there might have been changes in the malloc/free handling in the meantime. But I am not sure, I only started to test the lto build very recently .
13-11-2024
I'm wondering why these problems didn't show up when the current LTO options were being added, since the flattening was already in use by then. Is some of this because of the compiler version?
13-11-2024
The point of using flattening is to ensure some places that really matter get inlined. That empirically wasn't happening in some critical places with the automatic inlining. I don't think there's anything about LTO that would ensure that either. It may do more inlining than the compiler's automatic inlining, but there's no guarantee it will inline the places we really care about.
13-11-2024
RT Triage: warnings come from GC files, reassigning to GC sub-component for further evaluation.
12-11-2024
> Assuming there is a way to do so, would it help to exclude g1ParScanThreadState.cpp from LTO? It seems like LTO shouldn't provide much (if any) benefit vs the manually directed inlining via flattening and noinline. We could do so in the CFLAG settings of a single file https://github.com/openjdk/jdk/blob/2c1e4c381615ce52276f4bf331a1e7a845af4b6e/make/hotspot/lib/JvmFeatures.gmk#L168 but most likely not for the LDFLAGS . But on the other hand, we could also avoid the ATTRIBUTE_FLATTEN in the lot case because lto is doing own more aggressive inlining (https://developer.arm.com/documentation/dui0773/d/Optimization/Optimizing-across-modules-with-link-time-optimization see the statements about across module inlining)
12-11-2024
Assuming there is a way to do so, would it help to exclude g1ParScanThreadState.cpp from LTO? It seems like LTO shouldn't provide much (if any) benefit vs the manually directed inlining via flattening and noinline. Or would LTO still run afoul of warnings due to FORBID_C_FUNCTION and the associated warning disable pragmas seemingly not being applied? Or maybe JVM_CFLAGS_FEATURES and/or JVM_LDFLAGS_FEATURES need to include -Wno-attribute-warning?
12-11-2024
G1ParScanThreadState uses ATTRIBUTE_FLATTEN to tune the inlining of code in that class, in an attempt to ensure the desired fast paths are inlined, despite the size and other attributes of some of these functions that might (and empirically did) inhibit inlining in some critical places with at least some compilers. It also uses NOINLINE and assumed implicit non-inlining of definitions in other translation units to keep slower paths out of line, to limit code size. It looks like there are a couple of things going on here. One is that slow paths internal to the Stack implementation (and perhaps other places) are being flattened because there isn't any NOINLINE anywhere to prevent it and it's all template code, so source is not in another translation unit. So we're probably generating more inline code that we really want. That seems hard to avoid though. The other is that LTO seems to be applying flattening even across translation units. (That's not completely surprising.) So the assumption that the flattening won't apply to code in other TU's is invalidated by LTO. That's going to make flatting a lot harder to use. And as part of that we're reaching calls to ::malloc and ::free inside the NMT implementation. We've decorated those functions to prevent their use in normal code, with the specific uses by NMT using pragmas to permit their use. But that pragma warning suppression seems to not be honored by LTO, leading to warnings about calls to ::malloc and ::free. That seems like a bug in LTO?
12-11-2024
Looks like the ATTRIBUTE_FLATTEN in g1ParScanThreadState.cpp causes the trouble when using lto; when uncommenting it the link-time-optimization enabled build works : diff --git a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp index f81c3241a1a..5cb89b8129b 100644 --- a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp +++ b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp @@ -321,7 +321,9 @@ void G1ParScanThreadState::dispatch_task(ScannerTask task) { // Process tasks until overflow queue is empty and local queue // contains no more than threshold entries. NOINLINE to prevent // inlining into steal_and_trim_queue. -ATTRIBUTE_FLATTEN NOINLINE +// maybe trouble with link-time-optimization +// ATTRIBUTE_FLATTEN NOINLINE + void G1ParScanThreadState::trim_queue_to_threshold(uint threshold) { ScannerTask task; do { @@ -336,7 +338,8 @@ void G1ParScanThreadState::trim_queue_to_threshold(uint threshold) { } while (!_task_queue->overflow_empty()); } -ATTRIBUTE_FLATTEN +// ATTRIBUTE_FLATTEN + void G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet* task_queues) { ScannerTask stolen_task; while (task_queues->steal(_worker_id, stolen_task)) { @@ -583,7 +586,8 @@ oop G1ParScanThreadState::do_copy_to_survivor_space(G1HeapRegionAttr const regio } // Public not-inline entry point. -ATTRIBUTE_FLATTEN +// ATTRIBUTE_FLATTEN + oop G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr region_attr, oop old, markWord old_mark) {
12-11-2024
We have also some other similar looking warnings when building with link-time-optimization , however most come from g1 coding ; there might be some issue with the usage of ATTRIBUTE_FLATTEN in the g1 coding together with link-time-optimization : src/hotspot/os/posix/os_posix.cpp:935:3: warning: call to 'exit' declared with attribute warning: use os::exit [-Wattribute-warning] In function 'exit', inlined from 'vm_direct_exit' at src/hotspot/share/runtime/java.cpp:579:11, inlined from 'unrecoverable_writing_error' at src/hotspot/share/cds/metaspaceShared.cpp:948:17, inlined from 'report_out_of_space' at src/hotspot/share/cds/archiveBuilder.cpp:1416:47, inlined from 'expand_top_to' at src/hotspot/share/cds/archiveUtils.cpp:190:51, inlined from 'expand_top_to' at src/hotspot/share/cds/archiveUtils.cpp:186:7, inlined from 'append_intptr_t' at src/hotspot/share/cds/archiveUtils.cpp:257:16, inlined from 'do_bool' at src/hotspot/share/cds/archiveUtils.hpp:211:34: src/hotspot/os/posix/os_posix.cpp:935:3: warning: call to 'exit' declared with attribute warning: use os::exit [-Wattribute-warning] In function 'exit', inlined from 'vm_direct_exit' at src/hotspot/share/runtime/java.cpp:579:11, inlined from 'unrecoverable_writing_error' at src/hotspot/share/cds/metaspaceShared.cpp:948:17, inlined from 'report_out_of_space' at src/hotspot/share/cds/archiveBuilder.cpp:1416:47, inlined from 'expand_top_to' at src/hotspot/share/cds/archiveUtils.cpp:190:51, inlined from 'expand_top_to' at src/hotspot/share/cds/archiveUtils.cpp:186:7, inlined from 'append_intptr_t' at src/hotspot/share/cds/archiveUtils.cpp:257:16, inlined from 'do_tag' at src/hotspot/share/cds/archiveUtils.hpp:215:34:
08-11-2024