MPS issue job001707

TitleVM Arena never shrinks a generation zone set preferences.
Statusopen
Priorityoptional
Assigned userRichard Brooksby
OrganizationRavenbrook
DescriptionVM Arena never shrinks a generation zone set preferences.

The VM Arena maintains, for segment placement purposes, a set of zones
associated with generation (a generation for this purpose is a small
integer). This is the genZoneSet (array). Each generation's
genZoneSet is extended when a segment is allocated using that
generation's segPref (see vmAllocCom in vmarena.c).

It is essential that the genZoneSet for any particular generation be
allowed to shrink when that generation is no longer using a set of
zones. One important circumstance where this is required is when, for
whatever reason, different generations end up sharing zones. It must
be possible to reach a situation where the genZoneSets no longer
overlap.

An example of when this might be useful is given in the
logfile [1] with this extract:

Just after Collection 10 we see:

Arena 0010F000 {
  class 0005EC7C ("VM")
  genZoneSet[0]: 01110100001000000000000000000000
  genZoneSet[1]: 00001011110100000000000000000000
  freeSet: 00000000000011111111111111111111
  blacklist: 10000000000000000000000000000001
} Arena 0010F000 (0)
white set:01110101111100000000000000000000

The odd thing here is that the white set is not the union of some set
of genZoneSets. This is explained by the fact that the MPS is
collecting generations 0 and 1, so condemning all zones occupied by any
generation 0 or 1 objects, but some zones contain no objects even
though they are marked as being in some generation's genZoneSet. In
this case Zones 4 and 6 must contain no objects even though they are in
the genZoneSet for generation 1 (presumably that generation must have
once had objects in those zones).

In this case the MPS could reasonably remove zones 4 and 6 from
genZoneSet[1].
AnalysisNeed to do map over all segments collecting more accurate genZoneSets.
I think we can almost do this when a collection is started when all
segments that are to be condemned are iterated over. Almost all the
time exactly those segments are all the segments in a particular
generation.
How foundunknown
Evidence[1] //info.ravenbrook.com/project/mps/bran...gtag/code/log/20070809t153040-amcss.txt
Observed in1.108.0
Created byDavid Jones
Created on2007-09-07 13:55:27
Last modified byRichard Brooksby
Last modified on2013-06-16 07:22:15
History2007-09-06 DRJ Created.
2013-03-19 GDR Assigned to RB.
2013-06-16 RB Downgraded to "optional" as there is no evidence that this is affecting anyone (see job003499).