delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/28/07:28:40

Message-Id: <199704281117.NAA23974@grendel.sylaba.poznan.pl>
Comments: Authenticated sender is <grendel@[150.254.113.14]>
From: "Mark Habersack" <grendel AT hoth DOT amu DOT edu DOT pl>
Organization: PPP (Pesticide Powered Pumpkins)
To: Lorier <lorier AT ihug DOT co DOT nz>
Date: Mon, 28 Apr 1997 13:17:04 +0100
MIME-Version: 1.0
Subject: Re: Usage of directory entries
Reply-to: grendel AT hoth DOT amu DOT edu DOT pl
CC: alaric AT abwillms DOT demon DOT co DOT uk, Matthias DOT Paul AT post DOT rwth-aachen DOT de,
opendos-developer AT delorie DOT com
In-reply-to: <m0wL66q-000FmbC@hn.planet.gen.nz>

Once upon a time (on 26 Apr 97 at 23:57) Lorier said:

> >> A garbage collector is a process that deallocates memory automatically. a
> >> GC, you never call free() - you just leave memory lying around, and the
> >> cleans up after you. Now, a parallel GC runs as a seperate thread. The
> >> system looks at the amount of memory being allocated by the program, and
> >> amount of memory being found as unreachable by the GC. If the program is
> >> allocating faster than the GC is freeing, the GC gets a priority boost,
> >> fragmenting, and use it as a basis for the clock ticks allocated to the
> >> defragger.
> >mmm... sounds sensible. Do you know of any GC already working somewhere?
> 
> Java has a nice one.
Yes, but it's still an *application* garbage collector, and not a *system* 
one.

> I still think that running a defragger is rather useless if we can use a FS
> that doesn't require it :)
Exactly. 
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
  reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
  pieces of a ricochet...

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019