Agenda for February 28, 2018 OMR Compiler Architecture Meeting

[0xdaryl]

Agenda

1. Introductory remarks [ <5 mins : @0xdaryl ]
2. Compiler technology focus 2018 [ < 30 mins : @0xdaryl ]
3. Problems transmuting nodes discussion (Problems transmuting TR::Nodes #2338) [ @fjeremic ]

Details

Wednesday, February 28, 2018 @ 15:30 EST (GMT -5), 90 minutes maximum

Join WebEx (audio/screen sharing only): https://ibm.webex.com/ibm/j.php?MTID=m0d57c00f8d345214286fd668a648cc20
Meeting number: 921 005 012
Meeting password: omrrocks!

Call-in numbers (for audio only)

This meeting will be recorded and posted.

[0xdaryl]

Given this is the inaugural meeting I think the main topic will be introductory and provide some guidance on the direction of the open compiler technology over the coming months.

[fjeremic]

Whether appropriate or not for the first meeting, I'd like to restart the discussion started in #2297 (comment) on the design of node flags and the current state of the implementation in which several node flags share the same enum value.

I'm particularly concerned that this is not a feasible solution moving forward and something needs to be done to address this. The concern I see is optimizations transforming nodes via OMR::Node::recreate which currently blindly copies the flags. Since flag enumeration values are overloaded we get into weird scenarios where a flag that used to have no meaning for a particular IL suddenly does.

There is currently no way to determine what flags are valid to be copied over and what flags change meaning. We should discuss possible ways to move forward.

[0xdaryl]

As this was the first meeting, technical difficulties were bound to happen. Unfortunately, half of the recording is missing and on the recording we do have the sound from the participants is not great. We have made adjustments in subsequent meetings to greatly improve this.

The discussion on TR::Node flags (henceforth referred to as Node flags) proceeded with a proposal that the flag bits on a Node should not be overloaded to prevent accidental (and incorrect) settings when a Node is transmuted from one opcode to another. Furthermore, it may be possible to decouple the flags from the Nodes themselves if this could realize a footprint savings. However, concerns were raised about the potential fragility of decoupling Nodes from their settings and potential defects.

As the problems with aliased flags arise when Nodes are transmuted, there was some lengthy discussion around finding a "safe" state for Node flags. The idea being that when a Node is transmuted to another its flags are reset to the safe state which should cause no harm. However, the consensus was that given the mature state of development of the compiler code base, finding a safe state for flags for each IL opcode will be tedious and error prone. Many assumptions appear to be baked into the code already will be difficult to identify and remedy.

While footprint concerns were raised, what's missing from this discussion is some real quantitative data to support or refute those concerns. The following actions were agreed upon:

ACTION: @fjeremic volunteered to take an initial stab at purging the current Node flags to eliminate ones that are clearly not required anymore, and to identify candidates that could be eliminated because they are redundant or because the information could be gleaned some other way. This work can be tracked by #2338.

ACTION: With the Node flags purged into a minimal set, @fjeremic volunteered to unalias all node flags and expand the flags word(s) to accommodate and then run some memory footprint tests. Since OpenJ9 is the largest consumer of this technology and is challenged by the footprint consumed by Nodes, larger Java workloads should be run to measure this. In addition, JSR292 tests tend to create a lot of IL Nodes so including those in the mix will be an important measuring stick as well. These measurements should also include:

• tracking the number of failed compiles (due to increased memory consumption)
• measuring how often certain Node flags are set to determine their dynamic popularity. Less popular flags could be "retired" and perhaps replaced with other means of determining that information (the effectiveness of this, of course, depends on the particular flag).
  This data can be shared in Problems transmuting TR::Nodes #2338.