RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3]

[Thomas Schatzl]

On Mon, 13 Sep 2021 04:44:51 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.
>
> Yude Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolve TODOs

There is another option for storing whether this part of the BOT is unrefined yet: take a bit from the BOT values themselves to encode that.
I did not look whether this is actually possible with the current encoding, but is an option if that does not take away too much of the range of the backskip - at the moment we use the values 0-63 (*8 = 512) to encode the offsets within the card, all higher values are backskip values after all.
I.e. it might even be that extremely high backskip values which would not be used in all but huge arrays (if at all) are available for such a thing.
Just some weird idea that came to my mind...

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

PR: https://git.openjdk.java.net/jdk/pull/5039