RFR: 8345265: Minor improvements for LTO across all compilers [v2]

[Julian Waters]

On Fri, 28 Mar 2025 05:10:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > Wait, sorry to trouble you further, but what does nm --demangle --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by gcc 14 with LTO active yield as the largest symbol in the binary? (It should be the symbol listed at the very top)
> 
> This is my output; maybe I have to add that I used the 'normal' jdk head without patches, is that what I should do for a gcc14 build test?
> 
> ```
> nm --demangle --reverse-sort --print-size --size-sort images/jdk/lib/server/libjvm.so   | more
> 0000000000453ee0 000000000002320e t State::MachNodeGenerator(int)
> 0000000000970f70 0000000000018eb9 t CompilerToVM::initialize_intrinsics(JVMCIEnv*)
> 000000000140caa0 000000000000f018 b Matcher::mreg2regmask
> 0000000000993c80 000000000000a40d t JNIJVMCI::initialize_ids(JNIEnv_*)
> 0000000000ac16b0 0000000000009d16 t Matcher::Fixup_Save_On_Entry()
> 000000000143db00 0000000000008000 b _ZL9_elements.lto_priv.0
> 0000000001446d20 0000000000008000 b _free_list
> 000000000141e900 0000000000007d00 b DFSClosure::_reference_stack
> 00000000013d6d40 0000000000007668 d _ZL9flagTable.lto_priv.0
> 00000000013edf60 0000000000006c30 d VMStructs::localHotSpotVMStructs
> 00000000010463f0 0000000000006a06 t readConfiguration0(JNIEnv_*, JVMCIEnv*) [clone .isra.0]
> 0000000000d51dc0 00000000000067a2 t StubGenerator::generate_libmPow()
> 00000000010b12d0 0000000000006289 t G1ParScanThreadState::trim_queue_to_threshold(unsigned int)
> 0000000000e24550 00000000000061e8 t ClassVerifier::verify_method(methodHandle const&, JavaThread*)
> 0000000001076dd0 000000000000548d t State::DFA(int, Node const*) [clone .isra.0]
> 0000000000e1ba00 000000000000519d t VMError::report(outputStream*, bool)
> 00000000014521e0 0000000000005000 b TemplateInterpreter::_safept_table
> 000000000142cb60 0000000000005000 b TemplateInterpreter::_normal_table
> 0000000001431b60 0000000000005000 b TemplateInterpreter::_active_table
> 0000000000653790 0000000000004e12 t CompileBroker::print_heapinfo(outputStream*, char const*, unsigned long)
> 000000000075be40 0000000000004e0b t G1CollectedHeap::do_collection_pause_at_safepoint_helper()
> 0000000000b90260 0000000000004a41 t Parse::do_one_bytecode() [clone .part.0]
> 00000000010c1f20 00000000000049e6 t d_print_comp_inner
> 0000000000c1e180 0000000000004594 t ServiceThread::service_thread_entry(JavaThread*, JavaThread*)
> 00000000005ad7c0 0000000000004424 t C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)
> 0000000000d260b0 000000000000440a t PhaseStringOpts::replace_string_concat(StringConcat*)
> 0000000000e48920 00000000000042e5 t VM_Version::initialize()
> 0000000000afbad0 0000000000004240 t Method::init_intrinsic_id(vmSymbolID)
> 00000000010200d0 00000000000040ab t PSParallelCompact::invoke_no_policy(bool) [clone .isra.0]
> 000000000051f230 0000000000004054 t Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)
> 000000000065c060 0000000000004015 t Compile::Code_Gen()
> 0000000000663060 0000000000003fec t CompileBroker::compiler_thread_loop()
> 000000000070d9b0 0000000000003fd7 t ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*)
> 0000000000be8890 0000000000003f8e t PhaseChaitin::Split(unsigned int, ResourceArea*)
> 0000000000818730 0000000000003f82 t PhaseChaitin::build_ifg_physical(ResourceArea*)
> 0000000000fb1920 0000000000003f44 t SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType) [clone .constprop.0]
> 00000000007e2ab0 0000000000003f41 t PhaseCFG::global_code_motion()
> 00000000013e8580 0000000000003e10 d JVMCIVMStructs::localHotSpotVMStructs
> 0000000000db3b00 0000000000003dff t TemplateInterpreterGenerator::generate_all()
> 0000000000f436d0 0000000000003d92 t initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0]
> 0000000000d6b680 0000000000003d42 t StubGenerator::generate_libmTan()
> 00000000004ff560 0000000000003d28 t BCEscapeAnalyzer::iterate_blocks(Arena*)
> 0000000000a2bfb0 0000000000003cef t VM_RedefineClasses::load_new_class_versions() [clone .part.0]
> 000000000073fde0 0000000000003ca2 t G1CollectedHeap::do_full_collection(bool, bool)
> 0000000000e8e170 0000000000003bea t ZDriverMajor::run_thread()
> 000000000103ec00 0000000000003b81 t JvmtiEnv::RetransformClasses(int, _jclass* const*) [clone .isra.0]
> 0000000000d18c50 0000000000003b4d t StubGenerator::generate_md5_implCompress(StubGenStubId)
> 0000000000a97160 0000000000003b20 t PhaseIdealLoop::auto_vectorize(IdealLoopTree*, VSharedData&) [clone .part.0]
> 00000000013df000 0000000000003aa8 d ruleName
> 00000000005c7e90 0000000000003a9f t PhiNode::Ideal(PhaseGVN*, bool)
> 00000000006a1ef0 0000000000003a9f t State::_sub_Op_AddP(Node const*)
> 0000000000e86880 0000000000003a74 t ZGeneration::select_relocation_set(ZGenerationId, bool)
> --More--
> ```

I've spoken to the gcc maintainers, according to them problems with -fuse-linker-plugin can be a potential cause of the fiasco with the inlining here. Sorry to trouble you further, but what happens if you replace both instances of -fuse-linker-plugin with -fno-use-linker-plugin on Linux in JvmFeatures.gmk? Does any change occur in the nm output or is the resulting JVM massively bloated?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2766182048