[gambit-list] GC-related questions

Marc Feeley feeley at iro.umontreal.ca
Mon May 23 17:36:44 EDT 2011

On 2011-05-22, at 7:33 AM, Mikael wrote:

> Dear Marc,
> I have a certain GC time incurred on each GC, because on the gambit heap there's lots of procedures and maybe some closures produced by (eval).
> Those procedures will stay there forever, so I'd like to mark them as PERMANENT to the GC, so that they will stop taking time for the GC on each of its iterations.

You can't just mark a MOVABLE or STILL object to be PERMANENT and hope that it will work.  A permanent object must be in a memory area that is not scanned by the GC.  Moreover, all references contained in a permanent object must reference PERMANENT objects.  This allows the garbage collector to stop marking when it reaches a PERMANENT object.

> In relation with this, I wish to query you:
>  * Is there any way to enumerate all objects on Gambit's heap, so that I can mark them as permanent?

Enumerating all objects on Gambit's heap would require writing C code similar to the GC.  Alternatively, use similar code to the object serializing algorithm (object->u8vector).  In any case, even if you could enumerate the objects, you can't just mark objects as "PERMANENT" as explained above.

>  * Is there any way to resolve all GC dependencies that an object has? (So that I could dig out all the dependencies on the heap for those procedures and closures, and mark them as permanent that way.)

Check out object->u8vector.

> Also, though not equally centrally:
>  * How do I enable the ___DEBUG_ALLOC_MEM_TRACE define in lib/os.h? By switching  the #define ___DEBUG_ALLOC_MEM_TRACE_not line to #define ___DEBUG_ALLOC_MEM_TRACE  and then ./configure --enable-single-host --enable-debug ; make? When I do this, compilation fails.

I just tried it and it works!  Can you show the output of the make?

>  * Does Gambit use to do malloc:s with some particular size? Is it configurable?

I don't understand what you are asking...  Most GC parameters are defined in lib/mem.h .

>  * For Gambit's copying GC to work out, does it generally malloc space enough for the active heap + a copy of it, or does it have this ~2x the active heap space allocated only during gc:s and free the inactive space at the end of the iteration?

The 2x factor is only on MOVABLE objects.  Each MSECTION (section of movable objects) has a fromspace and a tospace.  So they are always allocated.  This is needed to guarantee that the Gambit GC will not run out of space when GCing the heap (it will raise an exception in an uncorrupted Scheme heap).

>  * How is it, for objects on the heap above a certain size, Gambit makes a separate malloc, and does not move them on GC anyhow, so there'd be no point in marking them as permanent anyhow - what's this limit?

From lib/mem.h:

 * ___MSECTION_BIGGEST is the size in words beyond which an object will
 * be allocated as a still object.  It must be <= ___MSECTION_FUDGE.

Note that STILL != PERMANENT...

>  * For study of the GC in lib/mem.c :
>      * What is the name of the entry point procedure to GC (I suppose, the C correspondent to ##gc)?

In lib/_kernel.scm you will find:

(define-prim (##gc)
  (let ((result
         (##c-code #<<end-of-code

          ___BOOL overflow;
          overflow = ___garbage_collect (0);
          ___RESULT = ___BOOLEAN(overflow);

    (if result

and in lib/mem.c you will find:

___BOOL ___garbage_collect
   ___P((long nonmovable_words_needed),
long nonmovable_words_needed;)

>      * Is this the only entry point procedure to the GC, or are there other entry points also, for instance some procedure to check if it's time to make a GC already, if so which is this procedure/are these procedures?

Some Scheme allocation functions callable from C (such as ___make_pair, ___make_vector, ___alloc_scmobj, ...) can also call ___garbage_collect.  Note that the FFI calls ___alloc_scmobj to convert C data to Scheme data.


More information about the Gambit-list mailing list