[darcs-users] Re: [BK] upgrade will be needed
zander at kde.org
Fri Mar 4 14:01:48 UTC 2005
On Friday 04 March 2005 13:33, David Roundy wrote:
> > I can see it's a solution, but it would also be interesting to see CPU
> > and virtual memory usage with different frequencies of kicking off a GC
> > run manually. Freeing up stuff sooner may give benefits that outweigh
> > the added cost of a GC run.
> There's a call in FastPackedString to performGC when allocating seriously
> large chunks of data, and you can make this called more frequently by
> tuning the definition of "seriously large". Even if you don't know
> haskell, it's pretty easy code to read. One of these days I've got to
> remove the hidious_mallock_hack...
It is my understanding that all the lessons I (and many others) learned
writing garbage collectors for Java gave pretty configurable ones for GHC.
One of the things ghc has is a split into different generations where only
'reachable objects' are copied between generations. Thereby deleting all
non reachable objects.
If an object survives a copy from on old to a newer generation a couple of
times it is deemed a 'long lasting object' and moved to a different pool
that is not checked (and copied) nearly as often as the newly created
The point here is that since GHC can (or should be able to) configure number
of generations, aging, sizing etc in a dynamical manner its very wise to
read up on how all this GC stuff is making your objects be deleted and how
one really big object can wreak havoc on having loads of GCs where the
profit (amount of freed bytes) per GC is quite low.
So far I get the impression that this level of GC interaction has not been
looked into, but maybe this post being on the users list does explain
ps. are large objects 'marked' as such so the GC will avoid copying them
between GC runs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20050304/bd4f552f/attachment.pgp
More information about the darcs-users