RFR: 8314512: IGV: clean up hierarchical layout code

Roberto Castañeda Lozano rcastanedalo at openjdk.org
Wed Nov 27 19:39:39 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...

Thanks for mitigating the performance regression, Toby! I benchmarked a version with your latest Java code changes ("layout-after-opts") and the version with the latest Java code changes and assertions disabled ("layout-after-opts-no-asserts"), see  [results.ods](https://github.com/user-attachments/files/17939304/results.ods). In summary, the Java code changes mitigate the regression to some extent (from the original 1.7x mean slowdown down to 1.3x), and additionally disabling the assertions flips the sign of the result and brings a mean 1.5x **speedup** over the original layout time. That's great, I wasn't aware that enabling assertions on IGV was so expensive!

I have also tested IGV, both manually and automatically by re-enabling assertions and laying out thousands of graphs in the sea of nodes, clustered sea of nodes, and control-flow graph views, with different combinations of filters enabled. I did not find any issue.

I plan to review the actual code changes tomorrow.

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

PR Review: https://git.openjdk.org/jdk/pull/22402#pullrequestreview-2465835515


More information about the hotspot-compiler-dev mailing list