8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp #22464

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

JDK-8343698 fixed LTO for gcc when compiling for platforms where the FORBID_C_FUNCTION mechanism is active, however the fix does so by inhibiting LTO for a specific file. This can hinder optimization, which is the end goal if one is indeed doing an LTO build. Fix the issue in a different way by disabling FORBID_C_FUNCTION entirely for os.cpp, which is where the error originates. This has a wide downstream effect, as os.cpp contains a call to os::malloc which contains the forbidden malloc that causes errors that cannot be suppressed by ALLOW_C_FUNCTION in an LTO build. This is a stopgap fix until FORBID_C_FUNCTION is fixed to work properly with LTO on all platforms. While here, also fix a memory leak in jvmciEnv.cpp

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: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp (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

00: Full (a357017f)

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

@@ -613,7 +613,7 @@ JVMCIEnv::~JVMCIEnv() {
  if (_init_error_msg != nullptr) {
    // 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

@@ -86,7 +86,7 @@
 // so uses of functions that are both forbidden and fortified won't cause
 // 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.)

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

src/hotspot/share/runtime/os.cpp

@@ -22,6 +22,9 @@
 *
 */

+// 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

@@ -22,6 +22,9 @@
 *
 */

+// 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

@@ -22,6 +22,9 @@
 *
 */

+// 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

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 [email protected] hotspot [email protected] 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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp #22464

8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp #22464

TheShermanTanker commented Nov 30, 2024 •

edited by openjdk bot

Loading

bridgekeeper bot commented Nov 30, 2024

openjdk bot commented Nov 30, 2024

openjdk bot commented Nov 30, 2024

mlbridge bot commented Nov 30, 2024

kimbarrett left a comment

kimbarrett Nov 30, 2024

kimbarrett Nov 30, 2024

kimbarrett Nov 30, 2024

kimbarrett Nov 30, 2024

kimbarrett Nov 30, 2024

TheShermanTanker commented Nov 30, 2024

8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp #22464

Are you sure you want to change the base?

8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp #22464

Conversation

TheShermanTanker commented Nov 30, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewing

bridgekeeper bot commented Nov 30, 2024

openjdk bot commented Nov 30, 2024

openjdk bot commented Nov 30, 2024

mlbridge bot commented Nov 30, 2024

Webrevs

kimbarrett left a comment

Choose a reason for hiding this comment

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

kimbarrett Nov 30, 2024

Choose a reason for hiding this comment

TheShermanTanker commented Nov 30, 2024

TheShermanTanker commented Nov 30, 2024 •

edited by openjdk bot

Loading