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

B. Document History

C. Copyright and License

This document is copyright © 2004, 2006 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Redistributions in any form must be accompanied by information on how to obtain complete source code for the this software and any accompanying software that uses this software. The source code must either be included in the distribution or be available for no more than the cost of distribution plus a nominal fee, and must be freely redistributable under reasonable conditions. For an executable file, complete source code means the source code for all modules it contains. It does not include source code for modules or files that typically accompany the major components of the operating system on which the executable file runs.

This software is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.