RFR: 8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp [v2]
Kim Barrett
kbarrett at openjdk.org
Tue Dec 17 14:54:04 UTC 2024
On Tue, 17 Dec 2024 14:51:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:
>> [JDK-8343698](https://bugs.openjdk.org/browse/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
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>
> - Merge branch 'openjdk:master' into patch-16
> - -fno-omit-frame-pointer in JvmFeatures.gmk
> - Revert compilerWarnings_gcc.hpp
> - General LTO fixes JvmFeatures.gmk
> - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
> - Merge branch 'openjdk:master' into patch-16
> - Revert os.cpp
> - Fix memory leak in jvmciEnv.cpp
> - Stopgap fix in os.cpp
> - Declaration fix in compilerWarnings_gcc.hpp
> - ... and 2 more: https://git.openjdk.org/jdk/compare/00943376...9d05cb8e
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.
src/hotspot/share/jvmci/jvmciEnv.cpp line 616:
> 614: // The memory allocated in libjvmci was not allocated with os::malloc
> 615: // so must not be freed with os::free.
> 616: 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
src/hotspot/share/runtime/os.cpp line 26:
> 24:
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP
This isn't needed if not using LTO.
src/hotspot/share/runtime/os.cpp line 26:
> 24:
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP
So far as I can tell, this doesn't work. I still get tons of `-Wattribute-warning`s when building
with LTO, because of similar problem from other files.
src/hotspot/share/runtime/os.cpp line 26:
> 24:
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP
This prevents precompiled headers from being used for this file. `-Winvalid-pch` will warn if enabled.
src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 89:
> 87: // forbidden warnings in such builds.
> 88: #define FORBID_C_FUNCTION(signature, alternative) \
> 89: [[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.)
-------------
Changes requested by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/22464#pullrequestreview-2470757627
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864123170
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864170998
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864210214
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864215385
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864125153
More information about the build-dev
mailing list