> > > Hmmm, the garbage collector is a black box and has its own
> > > complicated heuristics for managing memory usage, but you are
> > > describing a mechanism that depends rather heavily on certain
> > > assumed behaviours. At the least, that gives the garbage
> collector
> > > less flexibility to change its own behaviour, lest it
> invalidate the
> > > assumptions made by the external allocator.
> >
> > This is a situation where something is better than nothing. The
> > heuristics we used with Hugs were pretty lame -I don't
> think they even
> > worked as I'd intended- but they were good enough to get
> the job done.
> > In fact, the application ran brilliantly: small GC pauses, little
> > wasted memory.
>
> I am not sure what to do with this one. SimonM, did
> Alastair convince you by now that what he proposes is
> useful?
Well, perhaps, but I objected on the grounds that it couldn't be done
portably. Within the bounds of a single system, having such
functionality could well be useful, but it would be dependent on the
characteristics of the memory manager of that particular system. I'd
leave such things to individual implementations.
Cheers,
Simon
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
