> 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    621832         
> 0         0         0         0    261824...

Thomas Stuefe has updated the pull request incrementally with one additional 
commit since the last revision:

  Update src/hotspot/share/opto/chaitin.cpp
  
  Co-authored-by: Roberto Castañeda Lozano <robcas...@users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/dd7a06ad..2c56b216

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

PR: https://git.openjdk.org/jdk/pull/23530

Reply via email to