RFR: 8349835: C2: simplify IGV property printing
Christian Hagedorn
chagedorn at openjdk.org
Mon Sep 22 08:01:02 UTC 2025
On Fri, 22 Aug 2025 13:28:22 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:
> The code that prints node properties and live range properties is very verbose and repetitive and could be simplified by applying a refactoring suggested [here](https://github.com/openjdk/jdk/pull/23558#discussion_r1950785708).
>
> ### Fix
> Implemented the suggested refactoring.
>
> ### Testing
> Github Actions, Tier 1-3
src/hotspot/share/opto/idealGraphPrinter.cpp line 1082:
> 1080: lrg.mask().dump(&lrg_mask_stream);
> 1081: IdealGraphPrintRecord rec[] = {
> 1082: {1, "mask", buffer},
Thank for trying to clean this up! I see the benefit of doing it since it looks like we can get rid of the repetitions. But using this approach now feels like we squeezed in too much into a single generic method and fall back to arrays with structs with some optional fields that are sometimes set to null which is not easy to comprehend. And the method `visit_nodes()` is still quite large. What if we just had different methods or even classes for different properties? This helps with self-documenting the code and also avoids passing in some `nullptr` for unused values. For example (in pseudocode):
- node flag properties all share the same pattern:
class NodeFlags:
NodeFlags _flags;
print_properties() {
print_property(Flag_is_Copy, "is_copy");
print_property(Flag_rematerialize, "rematerialize");
...
}
print_property(flag, property) {
if (_flags & flag) {
print_prop(property, "true");
}
}
- For lrg: Could also create a class and store `lrg` as field. We could have different printing methods, for example for unconditional prints, for printing true etc.
This is just an idea, I have not actually tried it out. What are your thoughts about that alternative approach?
We might have even more opportunities to refactor `visit_node()` since there are some more repetitive patterns here and there. But this could also be done separately.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26902#discussion_r2367031472
More information about the hotspot-compiler-dev
mailing list