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

[Yude Lin]

On Tue, 10 Aug 2021 07:40:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> From what I understand from a brief look at the backwards scan prototype (I will continue a bit, and I may be wrong), the code actually implements scanning backwards the cards within claimed chunks. I wasn't really suggesting to scan backwards the cards, but claim the chunks (i.e. the set of cards a given thread will look at) from top to bottom addresses within the region. Or just have the first claim be the top chunk, or as a first task for a completely untouched region, have the thread explicitly update the BOT. Or after claiming a chunk, first fix the bot for that chunk, and then scan through.
> 
The prototype reverses both the chunk claiming process and the card scanning process in each chunk. Because I thought within each chunk there could also be repetitive work if we do forward scan.

> I am also trying to understand a little how serious the problem is in terms of actual performance hit by the duplicate work. It might be fairly high when not doing refinement at all as you indicate.
> 
I can do a test that compares the scan time with and without the duplicate work removed. And maybe change the concurrent refinement strength to create different groups. It seems the decisions depend on more data. E.g., if concurrent refinement is on, and the de-duplicate process isn't very effective in terms of reduction in scan time, then the process itself should be too heavy weight?

> As for concurrent BOT update, I believe that the existing concurrent refinement code already concurrently updates the BOT as needed afaik so that shouldn't be an issue (I need to go look in detail). One idea could be that after allocating a PLAB (in old gen only of course) we enqueue some background task to fix these. We know the exact locations and sizes of those, maybe this somewhat helps. We also know the chunk sizes that are used for scanning, so we know the problematic places.
> Something like the "root region scan" for marking (but we do not need to wait for it to complete during gc).

I misunderstood the concurrent update part. Now I see that you are actually suggesting moving almost the entire BOT fixing work out of the gc pause. I think that might further reduce the pause time. If I understand correctly, concurrent refinement fixes part of the BOT, but there are some leftovers. Now that the leftovers are also moved to the concurrent phase. I think it's worth some experiment too!

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

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