8345265: Minor improvements for LTO across all compilers #22464

TheShermanTanker · 2024-11-30T00:35:59Z

This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.

-fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
-flto is set to $(JOBS) instead of auto to better match what the user requested
-Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8345265: Minor improvements for LTO across all compilers (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464
$ git checkout pull/22464

Update a local copy of the PR:
$ git checkout pull/22464
$ git pull https://git.openjdk.org/jdk.git pull/22464/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22464

View PR using the GUI difftool:
$ git pr show -t 22464

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22464.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2024-11-30T00:36:58Z

👋 Welcome back jwaters! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-11-30T00:37:40Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2024-11-30T00:38:12Z

@TheShermanTanker The following labels will be automatically applied to this pull request:

build
hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-11-30T00:47:52Z

Webrevs

kimbarrett

I only noticed this had been changed back to Draft after I was mostly done looking
at it. But I don't think this should be done this way, esp. since it didn't seem to work
(as in suppressing warnings from LTO) for me.

kimbarrett · 2024-11-30T06:47:02Z

src/hotspot/share/jvmci/jvmciEnv.cpp

    // The memory allocated in libjvmci was not allocated with os::malloc
    // so must not be freed with os::free.
-    ALLOW_C_FUNCTION(::free((void*) _init_error_msg));
+    ALLOW_C_FUNCTION(::free, ::free((void*) _init_error_msg);)


Please do this bug fix change under a separate JBS issue & PR. I've created a JBS issue for it:
https://bugs.openjdk.org/browse/JDK-8345267
Fix memory leak in JVMCIEnv dtor

kimbarrett · 2024-11-30T06:49:49Z

src/hotspot/share/utilities/compilerWarnings_gcc.hpp

 // forbidden warnings in such builds.
 #define FORBID_C_FUNCTION(signature, alternative) \
-  extern "C" __attribute__((__warning__(alternative))) signature;
+  [[gnu::warning(alternative)]] signature noexcept;


Why are you making this change at all, let alone under this JBS issue?

Among other problems, noexcept is mostly irrelevant in HotSpot, since we build with
exceptions disabled. (There are a few places where noexcept affects semantics, like for
operator new, but otherwise there is no point.)

I was thinking about the extern "C" and I think it might not be needed. A method that was already declared extern "C" in a C library header will keep that linkage when it is declared again, even without extern "C". There's also the issue that this forbidding macro could declare methods that don't actually exist on the current platform, which I think(?) removing extern "C" helps prevent. There's also the strange case that not all platforms have C library methods that are extern "C" (Windows is a notable example), so this helps declaring things with conflicting linkages and causing an error. The noexcept was just to match the declarations in standard library headers, since they are supposed to be noexcept according to the Standard

kimbarrett · 2024-11-30T09:07:16Z

src/hotspot/share/runtime/os.cpp

 */

+// Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
+#define DISABLE_POISONING_STOPGAP


This isn't needed if not using LTO.

kimbarrett · 2024-11-30T10:31:26Z

src/hotspot/share/runtime/os.cpp

 */

+// Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
+#define DISABLE_POISONING_STOPGAP


So far as I can tell, this doesn't work. I still get tons of -Wattribute-warnings when building
with LTO, because of similar problem from other files.

kimbarrett · 2024-11-30T10:51:56Z

src/hotspot/share/runtime/os.cpp

 */

+// Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
+#define DISABLE_POISONING_STOPGAP


This prevents precompiled headers from being used for this file. -Winvalid-pch will warn if enabled.

TheShermanTanker · 2024-11-30T18:05:05Z

I only noticed this had been changed back to Draft after I was mostly done looking at it. But I don't think this should be done this way, esp. since it didn't seem to work (as in suppressing warnings from LTO) for me.

Yeah, I had noticed that it didn't work too, which is why I returned it to draft. It also causes VC to explode when compiling the Windows HotSpot, so that isn't ideal. I guess returning g1ParScanThreadState.cpp to LTO status will have to wait until FORBID_C_FUNCTION is properly fixed up to be LTO proof

TheShermanTanker · 2024-12-08T05:07:58Z

This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?

MBaesken · 2024-12-09T10:30:01Z

This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?

When I try to build with this change (with and without lto enabled) I run into

/openjdk/tools/devkits/x86_64-linux-gnu-to-x86_64-linux-gnu-fedora27-gcc11.3.0/x86_64-linux-gnu/sysroot/usr/include/unistd.h:520:14: error: conflicting declaration of 'char* get_current_dir_name()' with 'C' linkage
  520 | extern char *get_current_dir_name (void) __THROW;
      |              ^~~~~~~~~~~~~~~~~~~~

(maybe it is related to the devkit, maybe to pch I don't know)

TheShermanTanker · 2024-12-09T11:36:50Z

This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?

When I try to build with this change (with and without lto enabled) I run into
/openjdk/tools/devkits/x86_64-linux-gnu-to-x86_64-linux-gnu-fedora27-gcc11.3.0/x86_64-linux-gnu/sysroot/usr/include/unistd.h:520:14: error: conflicting declaration of 'char* get_current_dir_name()' with 'C' linkage
  520 | extern char *get_current_dir_name (void) __THROW;
      |              ^~~~~~~~~~~~~~~~~~~~
(maybe it is related to the devkit, maybe to pch I don't know)

It's related to the subtle change in FORBID_C_FUNCTION, I think unistd.h is being included before compilerWarnings.hpp somewhere. Well, at least I now know the current approach has this issue

TheShermanTanker · 2025-10-17T18:02:00Z

@magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

mrserb · 2025-10-17T18:43:50Z

Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

But as far I understand it will be much easy to implement for libs, do you know any blockers?

MBaesken · 2025-10-20T07:13:47Z

Hi, at the moment this is HotSpot only; We're unfortunately facing a very severe issue in G1 that can't seem to be solved. I'm currently focusing on making it work for HotSpot before introducing this for the native libraries.

But as far I understand it will be much easy to implement for libs, do you know any blockers?

Yes, the LTO build worked for the other JDK native libs when I enabled it there some months ago as a test.
(lto support for them is just a hack for now; but compiled nicely for me because those libs are much smaller/simpler than libjvm)

With GCC and LTO enabled, some libs get smaller e.g. for libfontmanager I saw a while ago 1.7M (without) to 1.1M (with LTO).
Speed improvements are hard to evaluate, the benchmarks used in OpenJDK often stress Hotspot and not so much single native JDK libs.

MBaesken · 2025-10-20T13:19:29Z

@magicus In JBS, I see a long conversation about LTO optimization for libraries aiming to cover all use cases. Maybe it's better to start with something smaller? For example, provide a way to enable it per library and per platform, so it can be incrementally adopted. Initial results for some libraries in the java.desktop look promising.

Currently we have OPTIMIZATION levels NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE for the native libs we build in OpenJDK. We could easily add also LTO or LTOHIGH + LTOSIZE if we want to distinguish even more.
But currently it is hard to evaluate what it is 'good' for.
Some people would expect improved performance from it; but we do not really have the benchmarks for the smaller JDK libs to prove that (at least I am not aware of it); that was also a problem when discussing to switch more libs to SIZE optimization.
Some people would expect improved/reduced size from using LTO; that is easier to 'prove' by looking at the libs sizes. But it is from what I saw not always true (for GCC with lto enabled however you often get smaller libs).

So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

mrserb · 2025-10-20T21:08:52Z

So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

kimbarrett · 2025-10-21T13:37:47Z

FWIW, I'm prototyping a possible change in g1ParScanThreadState.cpp that might
substantially reduce the amount of generated code there. It might not work
out; I haven't done any performance testing yet, and it's really easy to
introduce performance regressions when making changes to that code. But if it
does work, that might help with the problems here.

MBaesken · 2025-10-22T14:06:54Z

So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

Yeah, maybe something like

LINK_TIME_OPTIMIZATION := YES

that can be set by lib owners and passed as an optional parameter to SetupJdkLibrary / SetupNativeCompilation or similar.
We just need the lto settings per toolchain in 'make/autoconf' (probably the c/cxx/ld flags can be borrowed from Hotspot where the functionality was available for some time as a configurable 'JVMFeature') , and in case LINK_TIME_OPTIMIZATION was set for a lib, we have to add them in a proper way.
(On the other hand, we need some LIB owners testing and hopefully using it, otherwise the new functionality just rots in the m4-files)

I created
https://bugs.openjdk.org/browse/JDK-8370438
8370438: Offer link time optimization support on library level

MBaesken · 2025-10-24T13:01:38Z

So should we still offer LTO for more libs as an option to enable for the lib, even with the mentioned issues?

Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint. So it will be possible to mix size/perf and lto optimizations. Then later we can decide what to use by default.

I created a draft PR #27976 to support enabling LTO on library level.
(and for testing enabled it for 2 libs)

MBaesken · 2025-10-24T13:07:25Z

For Linux x86_64 / gcc 13 here are the sizes of the libs and debuginfos before (without) and WITH lto enabled on LIB level

libfontmanager.debuginfo   54155720  =>  38059440
libfontmanager.so          1874776   =>  1194264
libfreetype.debuginfo      4143416   =>  3761080
libfreetype.so             742472    =>  778024

For the debug info one can see a good size effect ; but not always the lib size decreases, for libfreetype.so it increases slightly.

bridgekeeper · 2025-11-22T03:00:50Z

@TheShermanTanker This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

TheShermanTanker · 2025-11-22T05:57:29Z

/touch

openjdk · 2025-11-22T05:58:41Z

@TheShermanTanker The pull request is being re-evaluated and the inactivity timeout has been reset.

mrserb · 2025-11-23T22:35:53Z

Just curious, how did you check that the “no omit frame pointer” option is needed? Did you see any test failures?

TheShermanTanker · 2025-11-24T07:59:24Z

Just curious, how did you check that the “no omit frame pointer” option is needed? Did you see any test failures?

gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise.

openjdk · 2025-11-25T08:52:15Z

@TheShermanTanker client has been added to this pull request based on files touched in new commit(s).

8345265

d6109a1

TheShermanTanker marked this pull request as draft November 30, 2024 00:36

DISABLE_POISONING_STOPGAP in compilerWarnings_gcc.hpp

b0b06bf

openjdk bot changed the title ~~8345265~~ 8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp Nov 30, 2024

Declaration fix in compilerWarnings_gcc.hpp

e725dba

openjdk bot added build build-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Nov 30, 2024

TheShermanTanker added 2 commits November 30, 2024 08:39

Stopgap fix in os.cpp

856a719

Fix memory leak in jvmciEnv.cpp

a357017

TheShermanTanker marked this pull request as ready for review November 30, 2024 00:43

openjdk bot added the rfr Pull request is ready for review label Nov 30, 2024

TheShermanTanker marked this pull request as draft November 30, 2024 03:09

openjdk bot removed the rfr Pull request is ready for review label Nov 30, 2024

kimbarrett suggested changes Nov 30, 2024

View reviewed changes

TheShermanTanker added 4 commits December 8, 2024 12:49

Revert os.cpp

b8d1c8a

Merge branch 'openjdk:master' into patch-16

55b89a1

Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp

5f9c8c8

General LTO fixes JvmFeatures.gmk

b244b86

TheShermanTanker added 2 commits December 17, 2024 22:41

Revert compilerWarnings_gcc.hpp

0c3b5c5

-fno-omit-frame-pointer in JvmFeatures.gmk

89e0cfd

TheShermanTanker marked this pull request as ready for review December 17, 2024 14:47

openjdk bot added the rfr Pull request is ready for review label Dec 17, 2024

MBaesken mentioned this pull request Oct 28, 2025

8370438: Offer link time optimization support on library level #27976

Closed

3 tasks

TheShermanTanker added 2 commits November 25, 2025 16:38

Merge branch 'master' into patch-16

7c0650e

Remove no longer needed warning disable in JvmFeatures.gmk

f709a7c

TheShermanTanker marked this pull request as draft November 25, 2025 08:39

openjdk bot removed the rfr Pull request is ready for review label Nov 25, 2025

TheShermanTanker added 7 commits November 25, 2025 16:43

Revert recent changes to flags-cflags.m4

5ca8cf1

Revert recent changes to flags-ldflags.m4

36703a7

Revert recent changes to spec.gmk.template

48e7258

Revert recent changes to NativeCompilation.gmk

570bacf

Revert recent changes to Flags.gmk

80f207b

Revert recent changes to CompileJvm.gmk

befc077

Revert recent changes to ClientLibraries.gmk

9599d09

openjdk bot added the client client-libs-dev@openjdk.org label Nov 25, 2025

TheShermanTanker marked this pull request as ready for review November 25, 2025 12:13

openjdk bot added the rfr Pull request is ready for review label Nov 25, 2025

8345265: Minor improvements for LTO across all compilers #22464

Are you sure you want to change the base?

8345265: Minor improvements for LTO across all compilers #22464

Conversation

TheShermanTanker commented Nov 30, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Nov 30, 2024

Uh oh!

openjdk bot commented Nov 30, 2024

Uh oh!

openjdk bot commented Nov 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Nov 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

kimbarrett left a comment

Choose a reason for hiding this comment

Uh oh!

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

TheShermanTanker Dec 8, 2024

Choose a reason for hiding this comment

Uh oh!

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

Uh oh!

TheShermanTanker commented Nov 30, 2024

Uh oh!

TheShermanTanker commented Dec 8, 2024

Uh oh!

MBaesken commented Dec 9, 2024

Uh oh!

TheShermanTanker commented Dec 9, 2024

Uh oh!

TheShermanTanker commented Oct 17, 2025

Uh oh!

mrserb commented Oct 17, 2025

Uh oh!

MBaesken commented Oct 20, 2025

Uh oh!

MBaesken commented Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mrserb commented Oct 20, 2025

Uh oh!

kimbarrett commented Oct 21, 2025

Uh oh!

MBaesken commented Oct 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MBaesken commented Oct 24, 2025

Uh oh!

MBaesken commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bridgekeeper bot commented Nov 22, 2025

Uh oh!

TheShermanTanker commented Nov 22, 2025

Uh oh!

openjdk bot commented Nov 22, 2025

Uh oh!

mrserb commented Nov 23, 2025

Uh oh!

TheShermanTanker commented Nov 24, 2025

TheShermanTanker commented Nov 30, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Nov 30, 2024 •

edited

Loading

mlbridge bot commented Nov 30, 2024 •

edited

Loading

MBaesken commented Oct 20, 2025 •

edited

Loading

MBaesken commented Oct 22, 2025 •

edited

Loading

MBaesken commented Oct 24, 2025 •

edited

Loading