RFR: 8314512: IGV: clean up hierarchical layout code
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Wed Nov 27 17:35:58 UTC 2024
On Tue, 26 Nov 2024 23:17:15 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:
> This refactoring enhances layer and node management by encapsulating computations within LayoutGraph, LayoutLayer, and LayoutNode, improving modularity and delegation of responsibilities for handling dummy nodes and self-edges to dedicated utility classes. Code duplication was reduced by consolidating common logic, such as edge reversal, into reusable methods, and optimizing processes like updating node positions and crossings. Additionally, method names were updated to better reflect their functionality,
>
> ### LayoutGraph
> The LayoutGraph class is responsible for organizing and arranging a graph's nodes and edges for visual display. It takes a collection of nodes (Vertex) and connections between them (Link) and structures them into layers, creating a hierarchical layout. The class handles complexities like edges that span multiple layers by inserting temporary "dummy" nodes to maintain a clear hierarchy. This organization helps ensure that when the graph is displayed, it is easy to understand and visually coherent, making the relationships between nodes clear and straightforward.
>
> ### LayoutLayer
> The LayoutLayer class represents a single horizontal layer in a hierarchical graph layout. It holds a list of nodes (LayoutNode) that are all on the same vertical level. This class provides simple methods to manage these nodes: you can add nodes to the layer, calculate the maximum height needed to fit all nodes, center the nodes vertically within the layer, and set their horizontal positions with proper spacing. In essence, LayoutLayer helps organize nodes neatly in a graph, making it easier to display the graph clearly and understand the relationships between nodes.
>
> ### LayoutNode
> The LayoutNode class represents a node in a hierarchical graph layout. It can be either an actual node from the original graph or a temporary "dummy" node added during the layout process to handle complex edge connections. This class stores important layout information like the node's position (x and y coordinates), size (width and height), layer level, and connections to other nodes through incoming and outgoing edges. It provides methods to calculate optimal positions, manage margins, and handle reversed edges, all aimed at arranging the nodes neatly in layers to create a clear and visually organized graph display.
>
> ### LayoutEdge
> The LayoutEdge class represents a connection between two nodes (LayoutNode) in a hierarchical graph layout. It stores information about the starting node (f...
Hi Toby, thanks for doing this! I realize this changeset is not a pure clean up but actually affects the layouts. Could you summarize the proposed layout edges? (condense output edges, extra vertical margin for nodes with input/output ports, changes to the crossing reduction heuristic, etc).
I found a couple of issues in the CFG view by playing around manually:
1. I get the following assertion error when opening the CFG view of the "Optimized finished" graph in [this file](https://github.com/user-attachments/files/17931456/foo.zip) and enabling the "Simplify graph" filter:
2. With this change, node labels in the CFG view are center-aligned (see right part of screenshot below), instead of left-aligned as expected (see left part of screenshot below):
The changeset introduces a significant regression (a slowdown of almost 2x) in the time to compute and show a layout, see full results here: [results.ods](https://github.com/user-attachments/files/17933245/results.ods). I used the following ten medium-size graphs: [igv-suite.zip](https://github.com/user-attachments/files/17933256/igv-suite.zip) and instrumented a baseline IGV and the IGV from this PR with the following change: https://github.com/openjdk/jdk/commit/862ed698454d45102335208203144ee9ac32a079.
Is the slowdown expected? Perhaps with a bit of profiling we could find whether there is some simple way to recover the original performance.
-------------
PR Review: https://git.openjdk.org/jdk/pull/22402#pullrequestreview-2464306425
Changes requested by rcastanedalo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/22402#pullrequestreview-2464330565
PR Review: https://git.openjdk.org/jdk/pull/22402#pullrequestreview-2464701035
More information about the hotspot-compiler-dev
mailing list