MachTemp are used in C2 to preserve registers to be used internally by ADL instructions. Since they are single-user virtual instructions, they should be scheduled as closely as possible to their users, to reduce register pressure. GCM [1] and LCM [2] try to achieve this, but post-scheduling transformations such as call-catch cleanup [3] may undo the result, as witnessed during the development of JDK-8322295. This RFE proposes identifying such transformations and ensuring that they keep MachTemp nodes and their users close to each other.
The issue is particularly noticeable when ZGC is used, since this collector makes heavy use of MachTemp nodes in its heap access ADL instructions. A simple way to identify "decoupled" MachTemp nodes is, for example, to look for MachTemp definitions that cross safepoints in OopFlow::build_oop_map.
[1] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/gcm.cpp#L1397-L1404
[2] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/lcm.cpp#L620-L623
[3] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/gcm.cpp#L1613-L1618
The issue is particularly noticeable when ZGC is used, since this collector makes heavy use of MachTemp nodes in its heap access ADL instructions. A simple way to identify "decoupled" MachTemp nodes is, for example, to look for MachTemp definitions that cross safepoints in OopFlow::build_oop_map.
[1] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/gcm.cpp#L1397-L1404
[2] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/lcm.cpp#L620-L623
[3] https://github.com/openjdk/jdk/blob/40b2fbd8207404961d3d23375b288cceafc3f902/src/hotspot/share/opto/gcm.cpp#L1613-L1618