RFR: Coalesce and fill old, pinned regions after old gen final mark
Kelvin Nilsen
kdnilsen at openjdk.org
Wed Jul 6 17:32:21 UTC 2022
On Wed, 6 Jul 2022 17:27:45 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> I would hope there is some existing code that rejects a region-pin request if the region has already been selected to be in the "cset". Actually, this probably will never happen because once a region has been selected to be in cset, then the mutator can no longer see the objects residing within that region. The mutator can only see the to-space replicas of these objects. So the mutator may try to pin the destination region, but will never try to pin a from-space (cset) region.
>
> @kdnilsen - You're right that the mutator _should_ not be allowed to pin regions in the cset. The load barrier should evacuate the object and the to-space region would be pinned. However, if there is an OOM failure during the evacuation, the mutator will be able to reach the from-space object and pin its region. This scenario is [handled in the degenerated cycle](https://github.com/openjdk/shenandoah/blob/ca939b69f95db2cb8ead9c9459b2d7712909a4b6/src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp#L171):
>
>
> // Before doing that, we need to make sure we never had any cset-pinned
> // regions. This may happen if allocation failure happened when evacuating
> // the about-to-be-pinned object, oom-evac protocol left the object in
> // the collection set, and then the pin reached the cset region. If we continue
> // the cycle here, we would trash the cset and alive objects in it. To avoid
> // it, we fail degeneration right away and slide into Full GC to recover.
Good catch. So we cannot entirely avoid this issue.
-------------
PR: https://git.openjdk.org/shenandoah/pull/149
More information about the shenandoah-dev
mailing list