RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
duke at openjdk.java.net
Tue Nov 9 07:41:38 UTC 2021
On Mon, 8 Nov 2021 14:47:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy.
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> Thomas review
First of all, pause time looks good from my test~
I was thinking that ``forward_to_block_containing_addr_slow`` should never be reached now, since all entries are now precise. However, when I add ShouldNotReachHere before ``forward_to_block_containing_addr_slow`` in ``G1BlockOffsetTablePart::forward_to_block_containing_addr`` I noticed that there are some exceptional cases and in these cases ``n`` always equals to ``addr``. Not sure if this is expected? I'll continue looking, just want to report this very quickly.
More information about the hotspot-gc-dev