[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.
Cheers,
Ralph.
More information about the darcs-users
mailing list