Tim Pollitt <[EMAIL PROTECTED]> writes:
> This feature is great, especially for programs which don't have flat
> heap usage needs. Finding a good default sizing policy, and a simple
> set of controlling options, may be a little tricky.
>
> >From the GC stats I get the impression that not all live structure is
> accounted as heap. If some objects (eg. arrays) incurring GC costs are
> ignored by resizing decisions, then it's possible for the collector to
> recover nearly all of a tiny heap, but spend nearly all CPU on tracing
> through an enormous array each time it collects the tiny heap.
That's true. Large objects (larger than 4k) aren't counted as live
heap. It's not clear whether this is the right or wrong thing to do:
the large objects aren't copied during GC, but they may be traced
(eg. a large array of pointers). Furthermore, the live data strictly
speaking should include the stack for each running thread (it doesn't
currently).
It's unlikely that the GC stats could be skewed by this: you'd need a
huge array with all elements pointing to the same object.
> I think rts.ps mentioned the possibility of using page fault stats to
> automatically tune sizing. In some cases the user may already have a
> good estimate of available real memory, and find it convenient to specify
> a size (between the limits) which should be exceeded only when really
> necessary.
I'm not sure whether you'd want to set this by hand or have the RTS
deal with it automatically, although I suspect the latter will give
better results. The amount of free real memory in the system will
likely fluctuate quite a bit, possibly during the run of the program
itself. The downside of letting the RTS decide how much memory to use
would be that it would start paging before it detected the fact and
reduced memory consumption. Better OS support would help.
Cheers,
Simon
--
Simon Marlow [EMAIL PROTECTED]
University of Glasgow http://www.dcs.gla.ac.uk/~simonm/
finger for PGP public key
