On Fri, 14 Feb 2025 09:34:18 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> Greetings, >> >> This is a rewrite of the Compiler Memory Statistic. The primary new feature >> is the capability to track allocations by C2 phases. This will allow for a >> much faster, more thorough analysis of footprint issues. >> >> Tracking Arena memory movement is not trivial since one needs to follow the >> ebb and flow of allocations over nested C2 phases. A phase typically >> allocates more than it releases, accruing new nodes and resource area. A >> phase can also release more than allocated when Arenas carried over from >> other phases go out of scope in this phase. Finally, it can have high >> temporary peaks that vanish before the phase ends. >> >> I wanted to track that information correctly and display it clearly in a way >> that is easy to understand. >> >> The patch implements per-phase tracking by instrumenting the `TracePhase` >> stack object (thanks to @rwestrel for this idea). >> >> The nice thing with this technique is that it also allows for quick analysis >> of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in >> there with a speaking name, and you can see the allocations inside that >> phase. >> >> The statistic gives us two new forms of output: >> >> 1) At the moment the compilation memory *peaked*, we now get a detailed >> breakdown of that peak usage per phase: >> >> >> Arena Usage by Arena Type and compilation phase, at arena usage peak of >> 58817816: >> Phase Total ra node comp >> type index reglive regsplit cienv other >> none 1205512 155104 982984 33712 >> 0 0 0 0 0 33712 >> parse 11685376 720016 6578728 1899064 >> 0 0 0 0 1832888 654680 >> optimizer 916584 0 556416 0 >> 0 0 0 0 0 360168 >> escapeAnalysis 1983400 0 1276392 707008 >> 0 0 0 0 0 0 >> connectionGraph 720016 0 0 621832 >> 0 0 0 0 98184 0 >> macroEliminate 196448 0 196448 0 >> 0 0 0 0 0 0 >> iterGVN 327440 0 196368 131072 >> 0 0 0 0 0 0 >> incrementalInline 3992816 0 3043704 62... > > Thomas Stuefe has updated the pull request incrementally with one additional > commit since the last revision: > > revert unnecessary copyright change > > We also save a copy of the counters to a global table that contains the N > > most expensive compilations. That table will be printed when one uses jcmd > > Compiler.memory. We also print it into the hs-err file. > > This is a new tool for me, but I'd appreciate it if there was the equivalent > of `PrintNMTStatistics` such that the table produced from the JCmd is also > printed on shutdown. > > Edit: print_final_report doesn't support verbosity, that'd be nice to have. Let's do this in a future RFE, if anyone misses it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2667638346
