[darcs-users] Re: [BK] upgrade will be needed
jch at pps.jussieu.fr
Thu Mar 3 00:00:31 UTC 2005
>> One is to put the burden on the programmer: the programmer needs to
>> explicitly ``close'' or ``destroy'' a handle before it becomes
>> eligible for garbage collection.
> But runs the risk that the programmer will free the alien resource too
> early, just like without GC.
>> associating with the handle a ``finaliser''
> But it does at least keep to the GC ideal.
The original sin was to allocate data behind the GC's back. Finalisers,
the fig leaf of functional programmers.
> [destroyPackedString] 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".
The reason why a well-designed GC can make consistently non-pessimal
decisions is that it has detailed knowledge of the history of the
program. When you allocate a FastPackedString, you've lied to the GC:
you've told it that you've allocated just a handful of bytes while in
fact you've mmapped a potentially huge area of memory that the GC
doesn't know about.
Which is why David was speaking about manually triggering a GC at the
right time -- in effect forcing the GC to scavenge or tenure large
amounts of stuff that it wasn't told about.
More information about the darcs-users