Re: Mmemory management and garbage collectors (was: Re: Using Hurd features

[Jonathan S. Shapiro]

On Mon, 2005-10-17 at 21:07 +0200, Marcus Brinkmann wrote:
> At Wed, 12 Oct 2005 13:24:35 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 
> > On Wed, 2005-10-12 at 18:29 +0200, Ludovic Courtès wrote:
> > > <address@hidden> writes:
> > > Guile for instance could certainly make good use of
> > > libhurd-mm's hooks, things of that sort...
> > 
> > If you are thinking about using memory management in support of garbage
> > collection, forget it. The literature on this is pretty comprehensive
> > and mostly negative.
> 
> This is interesting.  We have always used three example applications
> for the need to increase quality of service by providing more control
> over physical resource usage:
> 
> 1. Databases
>    Stonebraker "Operating System Support for Database Management"
>    
> 2. Garbage Collectors
>    (eg A.W. Appel and K. Li.  Virtual Memory Primitives for User Programs.)
> 
> 3. Continuous Media applications
>    (eg G.E. Mapp An Object-Oriented Approach to Virtual Memory Management)
> 
> These are the three examples given in Steven Hand: "Self-Paging in the
> Nemesis Operating System".  Maybe the result in 2. is not universal.
> Even if not, this would still leave the first and third applications
> as important fields to explore.
> 
> Anyway, we would be interested in some references about the negative
> results for garbage collectors.

The canonical place to start on garbage collectors would be Paul
Wilson's survey paper. Alternatively, you might look at the book
"Garbage Collection" by Jones and Lin, which is fairly comprehensive.
The Wilson survey is generally considered definitive.

The long and short of it is that the page fault handler latency is so
high on most operating systems that it is much cheaper to use
compiler-inserted barrier code.

You might look in particular at Tony Hosking's paper: Protection Traps
and Alternatives for Memory Management of an Object-Oriented Language.
Keep in mind that his result is considerably understated.

It could be that the reduced page fault handling times in a true
microkernel would make a difference, but it is unlikely that a major
implementer of a language runtime would want to do a special-purpose
implementation for a niche target.

I concur about databases, though I believe that the major issue there is
resource isolation -- preventing the I/O driven by one client from
decaching the work done my a second.

The thing about continuous media is tempting to believe, and I certainly
think that if you have the primitives you can do a better job than if
you don't. The problem with this as a rationale is that Windows Media
Player (WMP) does, in fact, work. On the server side it's a serious
issue, and it's a serious issue if you want predictable media handling
under constrained resource, but for the general client case it seems
like a claim that would be hard to convince my mother to believe after
MS demonstrates WMP.

Just my quick thoughts...

shap