Garbage collection

A crucial fact for clients of the garbage collector to know is that objects in the heap move. If all references to a traced heap object are from other traced heap objects, the collector may move the referent. Hence, it is a bad idea to hash pointer values. References from the stack or untraced heap into the traced heap are never modified.

The current collector is, by default, incremental and generational. The interruptions of service should be very small, and the overall performance should be better than with the previous collectors.

The use of VM protection is currently implemented only for the DS3100 and SPARC architectures. On other architectures, @M3novm is the default.

Note that the new optional background collection thread is not on by default; this may change in the future.

When you debug a Modula-3 program with m3gdb, you will find it simplest to run it with the @M3novm switch. More information on debugging in presence of the VM-synchronized garbage collector is available here.

Because of the use of VM protection by the collector, there are some additional constraints on what programs may legally do. For example, you cannot pass an address on the heap as an argument to sigvec(2). These restrictions are documented in RTHeapDepC.c. If they seem onerous, we might be able to eliminate some. Note also that fork() and vfork() are now relatively expensive operations, since they cause the current collection to finish; this situation may improve in a future release.


[Modula-3 home page]

m3-request@src.dec.com
Last modified on Mon Sep 25 18:23:53 PDT 1995 by heydon 
     modified on Wed May  4 08:03:11 PDT 1994 by kalsow 
     modified on Thu Jan  7 18:40:57 PST 1993 by muller