RFR: 8302738: IGV: refine 'Simplify graph' filter [v2]

Christian Hagedorn chagedorn at openjdk.org
Tue Mar 28 08:45:35 UTC 2023


On Mon, 27 Mar 2023 08:52:32 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> The "Simplify graph" filter abstracts away details from the graph that are typically unnecessary for debugging or analyzing the represented program. This changeset decouples this filter into two:
>> 
>> - "Simplify graph", which hides elements that are typically (but not always) unnecessary, and
>> - "Condense graph", which makes the graph more compact without loss of information.
>> 
>> Together, these two filters reduce the average graph size by a factor of 1.6x (nodes) and 1.9x (edges):
>> 
>> ![without-with-filters](https://user-images.githubusercontent.com/8792647/224118397-e6bd45d1-0b90-4d94-88ae-0a83f9ef20da.png)
>> 
>> Besides decoupling the "Simplify graph" filter, the changeset extends its functionality by:
>> - combining Bool and conversion nodes into their predecessors,
>> - inlining all Parm nodes except control into their successors (this removes lots of long edges),
>> - removing "top" inputs from call-like nodes,
>> - inlining more source nodes (such as MachTemp and ThreadLocal) into their successors,
>> - pretty-printing the labels of many inlined and combined nodes such as Bool comparisons or Catch projections (via a new filter that edits node properties), and
>> - using a sparse representation of nodes with empty inputs (e.g. call-like nodes after applying "Simplify graph").
>> 
>> The sparse input representation shows dots between non-contiguous inputs, instead of horizontal space proportional to the number of empty inputs. This helps reducing node width, which is known to improve overall layout quality:
>> 
>> ![dense-vs-sparse](https://user-images.githubusercontent.com/8792647/224118703-04f663b7-7a73-4e49-87d9-2acd8b98522b.png)
>> 
>> Note that the exact input indices can still be retrieved via the incoming edge's tooltips:
>> 
>> ![tooltip-with-input-index](https://user-images.githubusercontent.com/8792647/224119319-7f40fba2-1e9f-436e-a11c-8c3d428d46a6.png)
>> 
>> The control-flow graph view is also adapted to this representation:
>> 
>> ![sparse-in-cfg](https://user-images.githubusercontent.com/8792647/224119399-884e2516-a9a1-43fd-b5f5-747c99472ace.png)
>> 
>> #### Additional improvements
>> 
>> Additionally, this changeset:
>> - ensures that the selected filter subset is applied in the order listed in the "Filter" window (this is necessary for combining effectively the "Simplify graph" and "Condense graph" filters, but is also generally desirable for simplicity and consistency),
>> - introduces a complementary filter "Show custom node info" (enabled by default) that extends the labels of call and exception-creation nodes with custom information,
>> - extends the search functionality so that combined and inlined nodes can also be searched on and selected, and
>> - defines and documents JavaScript helpers to simplify the new and existing available filters.
>> 
>> Here is an example of the effect of the new "Show custom node info" filter:
>> 
>> ![show-custom-node-info](https://user-images.githubusercontent.com/8792647/224119545-fd564224-7ccc-4829-988e-77f05d25b3bc.png)
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that viewing thousands of graphs in the three views with different filter subsets enabled does not trigger any assertion failure (by instrumenting IGV to view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> Measured the combined filter application and view creation time for the sea-of-nodes view on a selection of 100 medium-sized graphs (200-500 nodes). On average, applying the new "Show custom node info" filter introduces a minimal overhead of around 1%, which motivates enabling it by default. Applying the "simplify graph" and "condense graph" on top actually gives a speedup of about 12%, since the additional filter application time is amortized by laying out and drawing fewer nodes. However, these filters are not enabled by default, since they cause a (minor) loss of information which is not desirable in every use case.
>> 
>> The graph size reduction and performance results are [attached](https://github.com/openjdk/jdk/files/10934804/performance-evaluation.ods) (note that each time measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Castañeda Lozano has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Increase the bold text line factor slightly
>  - Add extra horizontal margin for long labels and let them overflow within the node
>  - Select slots as well
>  - Remove code that is commented out
>  - Assert inputLabel is non-null

Thanks Roberto for your detailed answers!

> > When selecting a CallStaticJava node, the custom node info is sometimes cut depending on the zoom level (sometimes more, sometimes less)
> 
> Good catch, @chhagedorn! This is an existing issue in mainline IGV, you can reproduce it e.g. by showing a long property such as `dump_spec` in the node text. The issue just becomes more visible with the addition of custom node info in this changeset. As far as I understand, the node width is computed assuming it is selected (i.e. bold text) at 100% zoom level, and scaled proportionally to the selected zoom level. This assumes label fonts scale perfectly with the zoom level, which is not the case. As a result, very long node labels can overflow at different zoom levels than 100%. I don't see a better solution than multiplying the computed node width with a factor (`Figure::BOLD_LINE_FACTOR`) to account for the worst-case text overflow at any zoom level. This will not change the width of most nodes since this tends to be dominated by the input slots anyway, only for those nodes with long labels. I selected this factor experimentally to be of 6% of the total width. Hope this new vers
 ion fixes the issue you observed. If not, please try out and suggest a more appropriate factor.

That looks much better now! 6% seems to be a good value to go with. Thanks for fixing this general issue. 

> > Selecting an inlined node with the condensed graph filter does not work when searching for it. For example, I can search for 165 Bool node in the search field. It finds it but when clicking on it, it shows me an empty graph. I would have expected to see the following graph with the "outer" node being selected which includes 165 Bool.
> 
> Selecting, highlighting, centering, synchronizing etc. inlined and combined nodes ("slots" in IGV speak) has not been possible at all before this changeset. You can reproduce similar issues when using the "Simplify graph" filter in mainline IGV.

I see, I've never used the "Simplify graph" filter before. That's why I've only noticed this now.

> I included some basic (admittedly half-baked) support for this in this changeset (enhanced searching and parts of selecting, but not highlighting, centering, or synchronizing among tabs), but implementing full support would require a rather deep refactoring of IGV. I will not have time to work on such a refactoring in the coming weeks, so I propose to simply remove the partial support for slot interaction implemented provided by this changeset, so that we leave IGV in the same consistent state as before, and create a RFE for adding proper support in the future. @chhagedorn, @tobiasholenstein what do you think?

I agree with your suggestion to remove the partial implementation and try to fully support it later in a separate RFE. That might be the cleanest solution for now. And we could still take your current code as a starting point for that RFE .

> > Maybe the node info can be improved further in a future RFE, for example for CountedLoop nodes to also show if it is a pre/main/post loop or to add the stride.
> 
> Good suggestion! I agree that there is room for further exploiting custom node info in the future, loop nodes are excellent candidates :)

Great! :-) Can you file an RFE for that?

Thanks,
Christian

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

PR Comment: https://git.openjdk.org/jdk/pull/12955#issuecomment-1486452815


More information about the hotspot-compiler-dev mailing list