If you execute:
Repository>>reclaimAll
immediately following a markForCollection (for example, in a topaz script)
the reclaim can fail by returning false, or by returning true but not actually
reclaiming any pages.
This occurs because, after running markForCollection, the following operations
must occur:
1. The Gem running markForCollection sends the Stone the list of possibly
dead objects and returns. The Stone now holds the list of possibly dead
objects -- referred to as the "possible dead set" -- in RAM.
2. Now every Gem currently logged in the system must search the possible
dead set for any objects to which it holds references. Then it must commit
or abort,at which time it votes to either keep an object in the set, or
remove it (if it holds a reference).
-- NOTE --
Without commiting or aborting, Gems do not vote and can delay the
process
indefinitely. The vote cannot be finalized, garbage collection halts
at this point,
and commit records accumulate.
3. But what about Gems that aren't on the system now, but were when garbage
collection started? Their modified objects are in the commit record backlog,
in the write sets of each commit record, which the GcGem reads in order
to vote on their behalf.
Until these events occur, objects marked by markForCollection are not truly
dead, only "possibly dead", and their pages cannot be reclaimed.
If you call stopOtherSessions after the markForCollection, you terminate
the GcGem before it can vote on behalf of the logged-out Gems. Therefore,
objects in the possible dead set are not promoted to DeadNotReclaimed,
and the subsequent reclaimAll has nothing to reclaim.
You can tell when it's time to stop other sessions (if necessary) and run
reclaimAll by using statmonitor and Visual Statistics Display (VSD) to
watch three cache statistics:
When PossibleDeadSize and GcPossibleDeadSize fall to zero, and DeadNotReclaimedSize
goes up, you can run reclaimAll confident that the operation will perform
as intended.
Last updated: