| Title | Purpose of mps_arena_class_vmnz is unclear |
| Status | closed |
| Priority | nice |
| Assigned user | Richard Brooksby |
| Organization | Ravenbrook |
| Description | The documentation for mps_arena_class_vmnz [1] says: "This class is similar to mps_arena_class_vm but uses a simpler placement policy, that makes it slightly faster." If "slightly faster" were the only difference, why would you ever use mps_arena_class_vm? There must be a corresponding undocumented disadvantage. So what exactly is the use case for this arena class? |
| Analysis | RB: in fact there's a massive disadvantage: the lack of zones means that automatic memory management will be vastly slower. So if there is a use case, it must be for situations where there is no automatic memory management. GDR: For the moment I have removed mps_arena_class_vmnz from the documentation, but if there's a clear story about what it's for, I can restore it. The only difference is the allocation policy implemented by VMNZAllocPolicy, which ignores zones requested by pools, instead using ZoneSetUNIV. The effect is to allocate tracts first fit in each chunk. This may reduce the need to extend the arena due to fragmentation and possibly make allocation a bit faster, at the cost of making the GC's critical path much more expensive. I don't believe we have any current requirement to support this, and if one arose, we could handle it better by a keyword argument to the arena. RB 2014-01-28 |
| How found | inspection |
| Evidence | [1] <http://info.ravenbrook.com/project/mps.../manual/reference/#mps_arena_class_vmnz> |
| Observed in | 1.110.0 |
| Created by | Gareth Rees |
| Created on | 2012-10-19 13:57:15 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-05-21 21:06:16 |
| History | 2012-10-19 GDR Created. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 184783 | closed | 2014-03-13 15:28:06 | Richard Brooksby | Merging branch/2014-01-17/cbs-tract-alloc into master. |