RFR: 8256265 G1: Improve parallelism in regions that failed evacuation [v2]

Hamlin Li mli at openjdk.java.net
Tue Dec 14 10:21:17 UTC 2021


On Mon, 13 Dec 2021 14:28:35 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> One thing that we need to look more at is the clearing of the bitmap for old regions. This can probably be moved to a better location and be done in parallel to minimize the impact.

Thanks for reminding.

> > I think we can handle this zapping correctly, let me do some investigation and test.
> 
> Yeah, this is just a matter of coming up with a nice clean approach to handle it.
Agree.

> If we manage to remove one of the bitmaps there will no longer be a "prev" and a "next" bitmap, but just "the marking" bitmap. The bitmap is populated during the marking and during this point no old regions will be collected so there will be no need to clear parts of this bitmap. Once we are ready to do mixed collections the marking information in the bitmap is no longer needed and the bitmap will be cleared (this will be done concurrently, as it is today for the "next" bitmap). So what I mean by revised is that we need to adapt the solution to this new state of things.

I see, thanks for clarifying.

> Sounds great. The question is how we should move forward to make this most efficient. I could propose my PoC as a PR and then take it from there, allowing you to later work on making it parallelize better. The in the future attack the other optimizations.

Sure, I think your PoC is good.
I just had a draft version of parallelizing evac failure processing in chunks, I use it to evaluate the potential benefit of parallelism based on your PoC, seems my initial version does not bring much benefit, I think it might be because of mark bit map does not works well when I parallelize in chunks, I will invetigate further. here is my draft version:
https://github.com/openjdk/jdk/compare/master...Hamlin-Li:parallelize-evac-failure-v2-in-bm

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

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



More information about the hotspot-gc-dev mailing list