Memory Pool System Project Review

1. Introduction

This document is the result of a quick review of Ravenbrook's Memory Pool System project. The purpose of this document is to produce an initial project strategy and priority list of actions for the project, in order to achieve the project goals.

Not confidential. Readership: anyone. Status: complete; this document will not be updated.

2. Vision and Goals

The vision we have is: better memory management in all software, soon, with low effort.

We believe we can use the MPS and our mm knowledge to help progress towards this vision.

So our goals for the MPS Project are to:

goal_disseminate:
disseminate the knowledge and experience that was accumulated in developing the MPS and see it re-used
goal_reuse:
see the MPS re-used in new applications
goal_work:
gain opportunities for rewarding and interesting work in the field of memory management

But we do want to be objective. In particular we want objective measurement of whether and how much the MPS Project is helping progress towards the vision of better memory management in all software. We're not just beating our own drum here:

"I believe it's critical to get some kind of measurement of the MPS in place. The most important requirements for the MPS, I think, are to do with time and space, and with the effort, expertise, and skill needed to deploy it. We won't get adoption without competitive performance, and we won't get it unless the MPS is usable." [RB 2004-12-06]

3. Requirements

Each requirement is expressed as a statement, which is not yet true, but will be when the requirement is met.

3.1. Critical Requirements

Each of these is a measurable paraphrase of some aspect of the vision and/or goals: if we can't satisfy it, the project will have failed.

dev:
the MPS is an active and healthy development project
measurement:
we have objective measurement of MPS performance in a real world open-source setting

3.2. Essential Requirements

These requirements are some simple baseline 'targets'. We are confident that they are achievable, sensible, and desirable. Each is expressed as a statement, which is not true yet, but will be when the requirement is met.

paper:
at least one conference paper, derived from MPS technology, has been given by the end of 2006 [disseminate]
licensee:
at least one more commercial licensee of the MPS by the end of 2006 [re-use] [work]
opensource_use:
MPS is in ongoing third-party use in at least one open source project by the end of 2006 [disseminate] [re-use]

4. Strategy

The most important requirement is Critical Requirement dev. The rough strategy for this is:

  • make the internals of the MPS more accessible:
    • read-through of entire MPS source corpus, and some docs
    • glossary of MPS terms
  • defrost the MPS source and docs:
    • integrate external changes eg. from other parties
    • clear distinction between source&docs that are current and accurate, -vs- those that are obsolete
    • make it comfortable and simple to edit source&docs
  • do several integrations:
    • a simple client with manual memory allocation, showing benefit of pool-based deallocation;
    • Lua;
  • make the integration process much easier:
    • integrators manual
    • examples
  • work on measurement of MPS performance

A. References

[RB 2004-11-09] "MPS project review" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2004-11-09; <http://info.ravenbrook.com/mail/2004/11/09/14-22-27/0.txt>.
[RB 2004-12-06] "General strategy ideas" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2004-12-06; <http://info.ravenbrook.com/mail/2004/12/07/11-06-01/0.txt>.

B. Document History

2004-11-09 RB Created.
2004-12-13 RHSK Goals → Vision and Goals. Half a stab at Essential Requirements.
2004-12-13 RB Fixed HTML errors.
2004-12-13 RHSK Critical vs Essential requirements.
2006-01-19 RHSK Tidy and park.