README.GC

   1 -*-text-*-
   2
   3 This branch is a preliminary one which allows the GC to be replaced
   4 with Boehm's fully conservative collector.  (The current GC scans the
   5 stack conservatively, on the systems where that's been implemented,
   6 and treats the heap exactly.)  The Boehm collector has the advantage
   7 of supporting generational, incremental collection on some platforms,
   8 specifically under Linux.  [Perhaps the GCL GC could be investigated
   9 as an alternative.]
  10
  11 [`Generational' means that it divides allocated storage into regions
  12 depending on age of allocation and concentrates on collecting the
  13 youngest regions, which are assumed to have the highest object
  14 mortality rate.  `Incremental' means that it spreads the GC work so
  15 that pauses can be shorter and full collections aren't needed so
  16 frequently.  The Boehm collector also is generally well tuned, having
  17 had a lot of effort expended on it.  It doesn't do compaction of
  18 string storage like the current GC; it remains to be seen whether
  19 that's leads to important fragmentation in practice, but experience
  20 elsewhere suggests not.  The conservative marking isn't expected to
  21 leak significant space when all's said and done, but measurements
  22 remain to be made as we did for the current conservative stack
  23 marking.]
  24
  25 Needs a modified gc6.2alpha4 or later, built with
  26 -DAVOID_MMAP '-DPOINTER_MASK=$valmask'
  27 where $valmask is the same as VALMASK defined by lisp.h.  (Boehm
  28 included the pointer preprocessing in this version to cope with the
  29 Emacs tagging scheme.)
  30
  31 Currently we do the normal sort of GC -- not just in eval/funcall.
  32 (gc-cons-threshold is ignored.)  Does this need to be reverted given
  33 that we don't now do compaction, for instance?
  34
  35 xmalloc, xrealloc were replaced by the GC versions when building data
  36 structures which have a mark_... procedure or are traced from roots in
  37 Fgarbage_collect (with the corresponding free replaced by GC_FREE).
  38 The specpdl, catchlist, handerlist and backtrace_list are protected
  39 by the pointer chain from static storage.
  40
  41 We leak markers because they're kept alive by the buffer's chain.
  42 Ideally want a weak collection of them per buffer.  The #ifdef'ed out
  43 clause for GC_MARK_OBJECT in lisp.h should avoid this by masking the
  44 pointers to markers, but it causes crashes I haven't managed to debug
  45 yet.  This could use an extra set of eyes.
  46
  47 Weak hash tables don't work.  For completely weak tables, we could
  48 allocate the buckets with GC_malloc_atomic and use a finalization
  49 routine which tidied up un-marked entries.  It's probably better to
  50 treat all cases the same, and hide pointers to objects where they
  51 should be treated weakly.
  52
  53 It seems best to do allocation via malloc always (c.f. explicit sbrk
  54 in GC_unix_get_mem).  However, doing that gives random segvs after the
  55 first GC in a dumped Emacs under x86 lignux.
  56
  57 The mark bit in objects should be dispensed with under Boehm GC.
  58 (Doing that doubles the range of Lisp integers/heap pointers).
  59
  60 Need to check the buffer undo list stuff in Fgarbage_collect.
  61
  62 Something needs to be done for Gtk -- see xg_mark_data.
  63
  64 We probably need pre- and post-gc hooks in all gc/alloc.c.
  65
  66 There aren't any GC messages.
  67
  68 Messages from the GC need redirecting through Lisp somehow.  Probably
  69 a bunch of them should just be suppressed.
  70
  71 post-gc-hook is ignored.  Should it be invoked on partial
  72 collections?  (What use is it?)
  73
  74 GC times aren't accumulated yet.  See conditionals on PRINTTIMES in
  75 gc/alloc.c.
  76
  77 We could avoid copying string data in places where it's done to avoid
  78 losing with GC relocation during compaction.
  79
  80 The portable alloca needs to use GC_malloc to have the same effect as
  81 conservative stack scanning.
  82
  83 Don't know if this can work without NO_UNION_TYPE.
  84
  85 Might be worth allowing XGC_MALLOC to allocate using mmap (in an
  86 already-dumped Emacs), since the address doesn't have to fit into
  87 EMACS_INT and that might save significant allocation in precious Lisp
  88 address space.  Should be able to do similarly with string data.