RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
Aleksey Shipilev
shade at openjdk.org
Wed Jan 29 10:11:51 UTC 2025
On Wed, 29 Jan 2025 08:51:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:
>> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
>>
>> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem.
>>
>> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
>>
>> You can see the impact it has on Leyden here:
>> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `all`
>> - [x] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 550:
>
>> 548:
>> 549: // Add slop to avoid expansion during emit_stubs.
>> 550: return size + PhaseOutput::MAX_inst_size;
>
> Is this needed? `init_buffer` already bumps `code_req` up by `MAX_inst_size` immediately after calling `bs->estimate_stub_size()` and that headroom is maintained at each instruction emit.
Yes, I think so. Leyden experiments show this is needed. The slop added in `init_buffer` is going to be taken by normal code itself. This particular addition matches `maybe_expand_to_ensure_remaining(PhaseOutput::MAX_inst_size)` in `G1BarrierSetC2::emit_stubs` just below it. In other words, `emit_stubs` would always maintain `MAX_inst_size` remaining capacity, and that would happen after the normal code is emitted. So we need this slop addition here.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23333#discussion_r1933595140
More information about the hotspot-dev
mailing list