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

[Juliusz Chroboczek]

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

Yes.

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

                                        Juliusz