www.ravenbrook.com -

Topic

Talk for the University of Hertfordshire, 2004-12-01
Introduction
- who we are
- why we're here to talk
- what I'm going to talk about
Background
- What we mean by MM
  - Managing the memory of processes/programs
  - What is static MM?
  - What is manual MM?
  - What is automatic MM?
    - tri-colour marking
    - can be highly efficient -- MLWorks
  - What we don't mean
    - hardware MM
    - virtual memory
- Brief history of MM and GC
  - In the past
    - programs didn't live long
    - they were simpler
    - linker allocation
  - These days
    - complexity of software
    - data-dependency
    - high-level abstractions
- Why automatic MM/GC is important
  - Java, Perl, Python, C# all require it
  - Wasn't pervasive 5 years go.
  - Most people used to deride GC!
- Why GC is necessary
  - dynamic, non-stack-like behaviour
  - structure sharing
  - closures
The MPS
- Brief history of the MPS
  - Harlequin
  - Diverse MM problems
    - MLWorks, LispWorks, DylanWorks
    - ScriptWorks
    - The Lisp Machine at Symbolics
      - special-purpose hardware
  - MM Group
    - ~6 years, ~6 members
    - 30 years of effort
  - The end of Harlequin
    - Betting Dylan against Java
  - The MPS at Ravenbrook
    - open source
    - commercial licensing
    - dormancy
    - but not very rusty!
    - it's waking up!
- What's special about the MPS
  - Attributes
    - flexibility
      - can meet many sets of requirements without modification
      - wide variety of requirements
    - adaptability
      - can easily be modified to meet more (new) sets of requirements
      - new pool classes easy to bolt on
    - efficiency
      - time/space tradeoff
    - reliability
      - developed very rigorously indeed
  - Features
    - memory pools for flexibility and adaptability
    - manual and automatic MM in combination
    - incremental GC for responsiveness
    - in-line allocation for efficiency
  - Examples of pool classes
    - A
    - AMC
    - DL
      - example of domain-specific pool class
The future
- Our goals for the MPS
  - disseminate the knowledge and experience that we built up in developing the MPS and see it re-used
  - see the MPS re-used in new applications
  - gain opportunities for rewarding and interesting work in the field of memory management
- Project review happening now
Potential for collaboration
- Hidden good ideas
- Projects
  - Measurement
    - what measurements are appropriate
      - current research consensus
      - commercial requirements
    - creating measurement system
    - obtaining results for publication
    - writing a paper!
    - collaboration with visualization PhD?
  - Language integrations
    - Perl (Parrot), Python, Lua, Scheme, etc.
    - C--
    - Java?
    - Objective C
  - Other integrations
    - General drop-in malloc replacement
    - Kernel MM
    - Dynamic mach pager
  - Development
    - Efficient non-moving automatic pool
    - Exploit parallelism of modern architecture
    - Video game system?
  - Crossovers
    - Research specialized hardware requirements
    - Interaction with MM hardware architecture: cache, MMU, etc.
    - Specialized dynamic VM pagers
      - Fox? Haines? Nettles?
    - Interaction with VM OS architectures
How to get involved
- Join mps-discussion
- Contact Colin Egan
- Funding???
Where to find stuff
- Ravenbrook
- MPS
- MMRef
Summary
References
- The MPS Project <http://www.ravenbrook.com/project/mps/>.
Document History
- 2004-12-01 RB Wrote outline for talk this afternoon.
- 2004-12-06 RB Added history, references, and licence.
$Id: //info.ravenbrook.com/project/mps/doc/2004-12-01/herts-talk/index.html#1 $