PREV UP next StackThreads/MP: version 0.77 User's Guide

4.1.2: Controlling GC behavior

        void GC_gcollect(void);
@        int GC_dont_gc = 0;
@        int GC_free_space_divisor = 4;

GC_gcollect() explicitly triggers a GC at a point you desire. When GC_dont_gc is zero (this is the default), GC_MALLOC automatically triggers a GC when necessary. In this mode, you neither have to call GC_FREE nor GC_gcollect. When GC_dont_gc is non-zero, GC_MALLOC does not trigger GC (it always expands heap when heap overflows). You reclaim objects either by calling GC_gcollect at a point you desire or by calling GC_FREE on individual objects.

GC_free_space_divisor controls heap expansion policy. It only makes sense when GC_dont_gc is zero. The larger that value is, the more frequently GCs occur and the less aggressively the system expands heap. When heap overflows, SGC either triggers a GC or expands heap. Roughly, when this value is D, it tries to keep one Dth of heap available for allocation. More specifically, suppose a simple application that repeats allocating objects forever and keeps M bytes of them live all the time, the system tries to keep heap size (roughly) H to M + M/(D-1), so that H/D bytes are available for allocation. The long-term behavior in this case is that every H/D bytes of allocations trigger a GC, which reclaims H/D bytes from somewhere in heap. The default value is 4, meaning that it tries to keep 25% of the heap free for allocation. If you feel the system spends too much time on GC, set it to 3 or 2. Other values are hardly useful (note that D = 1 effectively prohibits GC).

There are other functions in SGC. See sgc.h and README.parallel in SGC.