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