RFR: Coalesce and fill old, pinned regions after old gen final mark

Kelvin Nilsen kdnilsen at openjdk.org
Wed Jul 6 17:17:23 UTC 2022


On Wed, 6 Jul 2022 00:40:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> The root of the issue is that mutator threads change `pin_count`, but only the gc threads transition (or synchronize) the pin count with `pinned` or `unpinned` states.
>
> Modulo yr concerns re the transitions into and out of `_pinned` state, I'd have thought that `_cset_pinned` could be considered the moral equivalent of not being in `_cset`. I'd expect that if an attempt were made to pin an object in a region that is in state `_cset`, the caller (mutator) would be forced to evacuate the object and then pin the destination region before the pinning call returns?

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.

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

PR: https://git.openjdk.org/shenandoah/pull/149


More information about the shenandoah-dev mailing list