ZBarrierSetC2::estimate_stub_size() always returns 0, because the list of stubs (barrier_set_state()->stubs()) is populated (by ZBarrierStubC2::register_stub()) after estimate_stub_size() is called. Here is an ad-hoc trace of a method compilation with two stubs:

ZBarrierSetC2::register_stub() (in_scratch_emit_size, nothing happens)
ZBarrierSetC2::register_stub() (in_scratch_emit_size, nothing happens)
ZBarrierSetC2::estimate_stub_size() (stubs->length() == 0, so returned size is 0)
ZBarrierSetC2::register_stub() (appends stub: stubs->length() == 1)
ZBarrierSetC2::register_stub() (in_scratch_emit_size, nothing happens)
ZBarrierSetC2::register_stub() (appends stub: stubs->length() == 2)
ZBarrierSetC2::register_stub() (in_scratch_emit_size, nothing happens)

The consequence is potentially extra unnecessary reallocations (but not malfunctioning, because underestimations are taken care of). The number of reallocations might be mitigated by the fact that additional space is allocated currently. This RFE proposes making the necessary adjustments so that estimate_stub_size() does take into account the actual size of the stubs.