At 11:20 AM -0700 6/11/97, Jonathan S. Shapiro wrote:
>My second claim is that a relatively shallow deallocation cache will
>address the majority of real uses. Here is why I think this is so:
>
> + allocation of pages/nodes happens N at a time for small N
> + deallocation of pages/nodes happens in bulk, because it tends
> to happen in response to one of the following operations:
>
> - destroying/truncating a segment
> - deleting a domain
>
> in both cases the entire space bank is arguably blown away,
> which is about as bulk a deallocation strategy as I can think
> of.
>
>If an object is expected to have a long-term life, it is already
>common practice to allocate it's space out of a dedicated space bank,
>which tends to support these assumptions.
In KeyKOS, objects were written to know how to destroy themselves (and return their space), without having to blow away a space bank. It sounds like you have closer to 1-bank/object.
>I guess my view is really that adding fragmentation management is a
>pain in the butt, so I'ld like to start without it and see what
>happens.
KISS (KeyKOS didn't get fragmentation management until the C version. We didn't do enough benchmarks to find out whether it made a difference.)
Bill Frantz | The Internet was designed | Periwinkle -- Consulting (408)356-8506 | to protect the free world | 16345 Englewood Ave. frantz@netcom.com | from hostile governments. | Los Gatos, CA 95032, USA