[mps-discussion] Memory Pool System release 1.114

[Gareth Rees]

Memory Pool System release 1.114 is out. You can read the release notes here.

In this release we’ve been focussed on:

1. Getting the complexity right. We want to keep pause times constant (and small) regardless of the size of the heap, and so there mustn’t be operations on the critical path that take time proportional to the size of the heap. Accordingly we’ve changed the organization of chunks (contiguous regions of address space resulting from extensions to the arena) so that they are stored in a tree instead of a linked list.

2. Separating concerns so that data structures are more flexible and thus more tunable. The most significant of the new tuning parameters is the arena grain size — the granularity with which the arena manages address space. By configuring the MPS_KEY_ARENA_GRAIN_SIZE keyword argument to mps_arena_create_k you can control this. There is a trade-off: larger grain sizes result in a smaller per-grain overhead, but also lead to more fragmentation because there can be more wasted space in each grain. But most applications will benefit from selecting a larger grain size.

3. Avoiding special cases. There are longer any arbitrary restrictions on the alignment of objects in MV, MVFF, and MVT pools. Collections of all automatic pool classes are now scheduled according to the same logic. There are now functions mps_pool_total_size and mps_pool_free_size for analyzing the space performance of all pool classes.

In addition, there are some new features:

4. Ambiguous interior pointers now keep objects in AMC pools alive. (Unless you set the MPS_KEY_INTERIOR keyword argument to FALSE when creating the pool.)

5. There’s a new “ANSI” pseudo-platform which doesn’t use any operating system features other than those provided by the ANSI Standard C library. (Actually the code for this has been in the MPS for a long time, but it is now possible to compile and test it.) This platform doesn’t provide memory barriers so it can’t maintain remembered sets and so the collection performance is poor. But the idea is that it can provide a first step in porting the MPS to a new platform, and that it might be possible in future versions to extend it to use software barriers.

Thanks to everyone at Ravenbrook for their hard work on this release.

-- 
Gareth Rees

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ravenbrook.com/pipermail/mps-discussion/attachments/20140707/a1aac0e3/attachment.html>