[darcs-users] Re: [BK] upgrade will be needed

David Roundy droundy at abridgegame.org
Fri Mar 4 12:33:48 UTC 2005

On Wed, Mar 02, 2005 at 10:49:11PM +0000, Ralph Corderoy wrote:
> > One is to put the burder on the programmer: the programmer needs to
> > explicitly ``close'' or ``destroy'' a handle before it becomes
> > eligible for garbage collection.  After closing, the handle structure
> > still exists, but it is unusable (typically, it contains a null
> > pointer or the fake file descriptor ``-1'').
> But runs the risk that the programmer will free the alien resource too
> early, just like without GC.

And with a lazy language like haskell, this is especially tricky, since
it's very hard to know when a given string is no longer needed.  The more I
think about this (and about version three, freeing by hand), the more I
think it's just too risky.  Better something like a "withXXX" idiom, which
can be idiot-proof.

> I can see it's a solution, but it would also be interesting to see CPU
> and virtual memory usage with different frequencies of kicking off a GC
> run manually.  Freeing up stuff sooner may give benefits that outweigh
> the added cost of a GC run.

There's a call in FastPackedString to performGC when allocating seriously
large chunks of data, and you can make this called more frequently by
tuning the definition of "seriously large".  Even if you don't know
haskell, it's pretty easy code to read.  One of these days I've got to
remove the hidious_mallock_hack...

You could also insert a performGC when we mmap a file:

hunk ./FastPackedString.hs 760
-               then do (fp,l) <- mmap f
+               then do performGC
+                       (fp,l) <- mmap f

which would cause darcs to call performGC pretty frequently.  "Usually" the
GC gets called pretty frequently anyways, since haskell is pretty much
constantly allocating memory, so the few times I've looked, it didn't seem
like things were getting held very long.

Ideally the Foreign module would allow us to tell the RTS what the "size"
of the contents of a ForeignPtr actually is.  When we aren't mmapping, we
use mallocForeignPtrArray, which means that the RTS *does* know how big the
contents are (or at least, it ought to, if it was paying attention).

You could also try configuring with --enable-debug-ps which I believe dumps
output every time a PackedString is allocated or freed.  But I haven't
tested it recently, so it may be broken.
David Roundy

More information about the darcs-users mailing list