This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Another new gc


Jim Blandy <jimb@red-bean.com> writes:

> I don't really understand why the heap expansion policy affects
> whether segregating GC marks from objects is faster that including
> them in the cells themselves.  It seems like this should either be
> irrelevant, or the performance should vary depending on how much
> memory the application uses.  Any ideas?
> 

I'm not quite sure I understand what you mean. The heap expansion
policy (expmem or fixed sizes is what I guess you're talking about)
doesn't really make any difference to the intrinsic speed of either
method of keeping marks. However, the current policy (keep making
segments larger and larger... IIRC, the third seg allocated with the
1.3 gc is > 1 meg, if it can get it) makes the total gc time a bit
smaller, but the pause for an individual gc starts to become
gross (not to mention the amount of memory it eats). 

The segregation of marks gains performance by making the gc time
proportional to the size of the heap (ok, actually, live_objects +
heap_cells/chunklet_size + dead objects), rather than the number of
live objects + the size of the heap... this brings the actual
performance much closer algorythmically to a copying collector (and
likely better since, in guile's case, many objects need some sort of
finalization, and a copying collector would have the overhead of
keeping track of them). There may be a few extra marking optimizations
that can be thrown in (currently, it gets a slight speedup by skipping
the big switch if the object isn't a port and it's marked; splitting
up scm_gc_mark could probably speed things up a little by playing
nicer with cache), but the only way to significantly speed up the
marking is to reduce the number of objects to be marked (the
generational stuff: most of the gc side implementation is written, but
it's going to require touching almost every part of guile to get it to
work, so I'd like the current bits (chunklets, ncells=2) to get some
testing before I wade into that).

-- 
Greg