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