Title | VM Arena never shrinks a generation zone set preferences. |
Status | open |
Priority | optional |
Assigned user | Richard Brooksby |
Organization | Ravenbrook |
Description | VM 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]. |
Analysis | Need 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 found | unknown |
Evidence | [1] //info.ravenbrook.com/project/mps/bran...gtag/code/log/20070809t153040-amcss.txt |
Observed in | 1.108.0 |
Created by | David Jones |
Created on | 2007-09-07 13:55:27 |
Last modified by | Richard Brooksby |
Last modified on | 2013-06-16 07:22:15 |
History | 2007-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). |