RFR: 8280396: G1: Full gc mark stack draining should prefer to make work available to other threads [v2]
Stefan Johansson
sjohanss at openjdk.java.net
Mon Jan 24 14:20:02 UTC 2022
On Mon, 24 Jan 2022 11:23:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
>>
>> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
>>
>> This is the change for g1.
>>
>> The CR shows some numbers how bad this can be.
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>
> - Merge branch 'master' into 8280396-g1-fullgc-stack-drain
> - Remove unused methods
> - Initial commit
Nice improvement. One comment, but I'm fine with the current approach if you prefer it.
src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 162:
> 160: follow_object(obj);
> 161: }
> 162: }
What do you think about instead of extracting all this into `drain_stack()` have something like `transfer_from_overflow()` as the first statement in in `pop_object()`? It would either return an object that can't be transferred or push it back to the overflow and just let pop do what it does today.
The problem I see with that is that `pop_object(...)` would have side effects that you wouldn't really expect, so if doing that maybe we should call it `drain_object_stack(...)` or something like that.
-------------
Marked as reviewed by sjohanss (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7175
More information about the hotspot-gc-dev
mailing list