RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size [v2]

[Aleksey Shipilev]

On Thu, 30 Jan 2025 11:58:04 GMT, Aleksey Shipilev <shade 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`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Leyden-specific additions, plainly estimate the stubs size

Ooof. I added this assert on top of this PR:


diff --git a/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp b/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
index 2edc827401d..cadb7988214 100644
--- a/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
+++ b/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
@@ -546,6 +546,11 @@ int G1BarrierSetC2::estimate_stub_size() const {
     size += cb.insts_size();
   }
 
+  if (size > 0) {
+    ResourceMark rm;
+    fatal("Non-zero C2 G1 stubs in %s", C->method()->name()->as_klass_external_name());
+  }
+
   return size;
 }


...ran `tier{1,2,3}` and hit it exactly zero times.

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

PR Comment: https://git.openjdk.org/jdk/pull/23333#issuecomment-2624856901