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