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] |
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