Updates to FFI spec
Alastair Reid
alastair at reid-consulting-uk.ltd.uk
Tue Aug 13 06:45:17 EDT 2002
> 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.
So, no, I don't see a heavy dependence or an extreme sensitivity to GC
behaviour.
>> (In the image processing example, images were megabytes and an
>> expression like (x + (y * mask)) would generate 2 intermediate
>> images (several megabytes) while doing just 2 reductions in
>> Haskell.)
> I think I'd be tempted to try to use a more predictable allocation
> scheme given the size of the objects involved. Perhaps arenas?
Aren't arenas a form of explicit memory management?
Explicit memory management was inappropriate for this example because
the objects were manipulated by non-IO operations: programmers
couldn't track the lifetime of an object because it depended on the
order that thunks were evaluated. Note that this is _exactly_ what
MallocPtrs/ ForeignObjs/ ForeignPtrs were invented to deal with.
(Indeed, the first ever application was a (different) image processing
library.)
> But there seems to be no way to reasonably decide how often one
> should call these. Doesn't it depend on the garbage collector's own
> parameters too?
It probably does. It might even vary from one kind of application to
another. But I don't think it is very sensitive to those parameters.
The goal here is to behave tolerably (e.g., not do a full GC on a
100Mb heap 20 times per second) not optimally.
[other topics answered separately]
--
Alastair
More information about the FFI
mailing list