RFR: 8373495: C2: Aggressively fold loads from objects that have not escaped [v17]
Quan Anh Mai
qamai at openjdk.org
Fri Jan 16 12:16:34 UTC 2026
On Thu, 15 Jan 2026 19:30:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>>
>> - Merge branch 'master' into loadfoldingigvn
>> - Early return when not a heap access
>> - Fix escape at store
>> - Fix outdated and unclear comments
>> - copyright year, return, comments, whitespace
>> - Merge branch 'master' into loadfoldingigvn
>> - ea of phis and nested objects
>> - Add test scenarios
>> - Add a flag to turn off the feature
>> - Much more comments, refactor the data into a separate class
>> - ... and 9 more: https://git.openjdk.org/jdk/compare/19c31186...c275e6e6
>
> What amount of functional testing has been done?
@iwanowww I have run the latest version with tier1-tier4 and hs-comp-stress.
@dlunde Thanks for your comments, I have addressed them.
> src/hotspot/share/opto/memnode.cpp line 714:
>
>> 712: bool is_known_instance = addr_t != nullptr && addr_t->is_known_instance_field();
>> 713: LocalEA local_ea(phase->is_IterGVN(), base);
>> 714: TriBool has_not_escaped = is_known_instance ? TriBool(true)
>
> IMO `TriBool` doesn't hold its weight here. As an alternative, encapsulating caching logic inside `LocalEA` and unconditionally querying it for escape state would look cleaner and easier to reason about.
I took a try, but I find it not compelling, the caching is the consequence of `find_previous_store` keeping walking from a node to its user. So, if a node does not observe that `base` has escaped, its user should not do so, either. Moving this logic to `LocalEA` seems not logical from that POV.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28812#issuecomment-3759763066
PR Review Comment: https://git.openjdk.org/jdk/pull/28812#discussion_r2698287188
More information about the hotspot-compiler-dev
mailing list