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

Ralph Corderoy ralph at inputplus.co.uk
Wed Mar 2 22:49:11 UTC 2005

Hi Juliusz,

Thanks for the explanation.

> 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.

> The second one is to kindly ask the garbage collector to destroy the
> alien resource before it discards it.  This is done by associating
> with the handle a ``finaliser'', a function that does The Right Thing.
> As the GC does not necessarily destroy garbage in a timely manner,
> this might cause temporary memory leaks, which is what we're seeing.

But it does at least keep to the GC ideal.

> The third solution is to use both methods: provide a manual ``destroy''
> operation, and *also* use finalisers in case the programmer forgets to
> close the handle.  This is the solution used for file handles.

So it too can suffer from the first problem, which I think is what David
was concerned about.

> Unless I'm mistaken, Darcs' FastPackedStrings use solution 2: they
> rely on the garbage collector to unmap the mapped data and provide no
> manual ``destroy'' interface.  If we add a destroyPackedString
> function while keeping the finalisers, we could then incrementally add
> calls to destroyPackedString where there are found to be safe.

And that's probably the tricky bit.  It would seem to remove one of the
benefits of a GC'd language if we have to rely on the programmer when GC
will "typically make better decisions".

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.



More information about the darcs-users mailing list