RFR: 8272083: G1: Record iterated range for BOT performance during card scan
Thomas Schatzl
tschatzl at openjdk.java.net
Mon Aug 9 11:37:36 UTC 2021
On Sat, 7 Aug 2021 04:56:08 GMT, Yude Lin <github.com+16811675+linade at openjdk.org> wrote:
> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
>
> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.
Just one initial thought: did you consider distributing the cards to scan from higher addresses to lower ones? Maybe this will remove some of this excess work - i.e. when the other threads will start helping for a given region, the BOT has already been fixed up for them.
Another consideration could be fixing the BOT concurrently up to the highest marked card.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5039
More information about the hotspot-gc-dev
mailing list