RFR: 8282024: add EscapeAnalysis statistics under PrintOptoStatistics [v14]

[Xin Liu]

On Fri, 20 May 2022 23:59:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/opto/escape.cpp line 3756:
>> 
>>> 3754: 
>>> 3755: void ConnectionGraph::print_statistics() {
>>> 3756:   // EA stats might be slightly off since objects might be double counted due to iterative EA
>> 
>> I don't understand. your approach almost worked in last revision.  All you need to do is to adjust for the last iteration. 
>> 
>> This revision drops it. I don't think it would be "slightly" off, even double counted is optimistic.  A java object will be counted repeat if iterEA iterates N times.  My concern is the final statistical counters become incomparable. 
>> 
>> Why did you drop snapshot approach in https://github.com/openjdk/jdk/pull/8019/commits/0805514aec4c3d0bd5ec935c089e315e4b37c7fa?
>
> @navyxliu, please, explain what do you mean "snapshot approach" and suggest how we should do it.

In previous revision, @aamarsh used 3 data members of Compile.  This tuple is a snapshot. 


_local_no_escape_ctr
_local_arg_escape_ctr
_local_global_escape_ctr


ConnectionGraph::escape_state_statistics() initializes them all zeros and categorize Java objects of the connection graph. 

here is the framework. 

   do {
        EscapeAnalysis();
        MacroExpand.eliminate_macro_nodes();      
    } while (progress?);

#ifndef PRODUCT
    Atomic::add(&ConnectionGraph::_no_escape_counter, _local_no_escape_ctr + total_scalar_replaced);
    Atomic::add(&ConnectionGraph::_arg_escape_counter, _local_arg_escape_ctr);
    Atomic::add(&ConnectionGraph::_global_escape_counter, _local_global_escape_ctr);
#endif

Both you and @JohnTortugo  pointed out that there was a bug in previous revision. We overlook that non-escaped objects are double-counted in last iteration. I think it's amendable.  

I call this snapshot approach because it uses the snapshot of last iteration to update global statistical counters.  all intermediate snapshots are drop. Allow me to write down @aamarsh 's approach. 

The number of Java object `JO` is from user-program by nature.  EscapeAnalysis breaks them down into 3 categories. non-escaped, arg-escaped and global escaped.  Without iterative EA, we can report this snapshot to statistical counters.

With iterative EA, a problem arise. Some objects elided in  previous iteration of MacroExpansion. if we use last snapshot, we have to add those eliminated java objects. Let's say iterative EA iterates N times in total. `E` is the number of eliminated java object from 1 to N-1 iterations (exclude the last iteration here).  

Since all eliminated objects must be non-escaped, so we add E back to _no_escape_counter. We account for all java objects of this compilation unit.  

    Atomic::add(&ConnectionGraph::_no_escape_counter, _local_no_escape_ctr + E);
    Atomic::add(&ConnectionGraph::_arg_escape_counter, _local_arg_escape_ctr);
    Atomic::add(&ConnectionGraph::_global_escape_counter, _local_global_escape_ctr);


In this way, We keep track of all java objects of this CU  for iterative EA. I think it's accurate. 

JO = _local_no_escape_ctr + E + _local_arg_escape_ctr  + _local_global_escape_ctr


I suggest to hoist the variable `PhaseMacroExpand mexp` out of loop and make it stateful to track E.

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

PR: https://git.openjdk.java.net/jdk/pull/8019