RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v2]

Roberto Castañeda Lozano rcastanedalo at openjdk.org
Fri Aug 9 12:03:37 UTC 2024


On Sun, 21 Jul 2024 08:21:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Roberto Castañeda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Build barrier data in G1BarrierSetC2::get_store_barrier() by adding, rather than removing, barrier tags
>
> src/hotspot/cpu/x86/gc/g1/g1_x86_64.ad line 86:
> 
>> 84:     // an indirect memory operand) to reduce C2's scheduling and register
>> 85:     // allocation pressure (fewer Mach nodes). The same holds for g1StoreN and
>> 86:     // g1EncodePAndStoreN.
> 
> I'm not convinced that this is beneficial. We're wasting a temp register just for an addition?

I agree that using indirect memory operands is the most readable choice, and is slightly less wasteful from a register usage perspective. However, when I tried this choice a couple of months ago, I observed timeouts in some CTW runs, which as far as I remember were caused when LCM processed huge basic blocks with lots of memory writes (e.g. arising from static initializations of large String arrays such as in [here](https://github.com/apache/lucene/blob/ea562f6ef2b32fe6eadf57c6381d9a69acb043c7/lucene/analysis/common/src/java/org/apache/lucene/analysis/en/KStemData1.java#L47-L748)), in combination with C2 stress options. In these scenarios, the large number of additional Mach nodes seemed to cause the timeouts. I settled for materializing the store address internally to guard against such corner cases. I did not see any significant performance difference between the two choices in my benchmark results.

I would like to study whether LCM can be made more robust in this scenario, which would enable using indirect memory operands here, but I think this would be best addressed in a separate RFE. Would it be OK by now to extend the code comment with the details provided in the above explanation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1711337413


More information about the hotspot-compiler-dev mailing list