doc/internals-notes/eden-pages

   1 Design for new page types in support of asynchronous
   2 determination of ambiguous roots.
   3
   4 Background: concurrency is only a problem pertinent
   5 to generation 0 with open per-thread allocation regions.
   6 Generations 1 and up are manipulated by the GC and will not have
   7 open regions when threads are initially stopped.
   8 If only generation 0 is to be collected, then each
   9 thread can stack its own stack.
  10 If generation 1 or higher is to be collected,
  11 the GC'ing thread will have to scan all stacks.
  12
  13 PAGE_TYPE_EDEN_CONS:
  14 * Pages are initially filled with 0xff.
  15 * All objects are conses.
  16 * Examining an arbitrary word will, with 100% certainty,
  17   determine that the word starts an object or does not.
  18   (Any <-1,-1> wordpair can not possibly be a cons)
  19 * Differs from CONS in that ordinary CONS is not prezeroed.
  20
  21 PAGE_TYPE_EDEN_BOXED:
  22 * Pages are initially zero-filled.
  23 * All objects are headered.
  24 * No object contains a raw slot.
  25 * Examining an arbitrary word will, with 100% certainty,
  26   determine that the word starts an object or does not.
  27   (Any word containing 0 can not possibly start an object.)
  28 * Acceptable primitive types:
  29   - instance with no raw slots
  30   - funinstance without embedded trampoline
  31   - ratio, (complex rational)
  32   - closure, value-cell, weak-pointer
  33   - simple-array, simple-vector-nil, simple-vector
  34   - complex-{base-string,character-string,bit-vector,vector,array}
  35 * Lockfree list nodes should be allowed on eden boxed pages,
  36   but we need more flag bits: one bit which says whether it can
  37   be initially allocated to BOXED (it won't contain random bits)
  38   and one which says whether it may be transported to BOXED.
  39   Generations > 1 do not use scavenge methods on BOXED pages,
  40   so it would not be allowed to have a list node there.
  41 * Differs from BOXED in that ordinary BOXED may not contain
  42   any object that demands a type-specific scavenge method.
  43
  44 PAGE_TYPE_EDEN_MIXED:
  45 * Pages need not be zero-filled (in theory).
  46 * All objects are headered.
  47 * Objects potentially contain one or more raw slots.
  48 * A bitmap of object start addresses is maintained by the allocator.
  49 * Acceptable primitive types:
  50   - bignum, double-float, (complex float)
  51   - symbol, mixed instance and/or instances made by %MAKE-INSTANCE
  52   - funinstance with embedded trampoline
  53   - sap, fdefn, simd-pack{-256}
  54   - simple-unboxed-vector
  55 * Differs from MIXED in that normal MIXED has no bitmap and will
  56   usually not contain instances that lack raw slots.
  57
  58 Similarities:
  59 * Type-specific scavenge methods are required for EDEN pages
  60   except for CONS.
  61   In the case of BOXED, this is due to presence of weak pointers,
  62   weak vectors, and address-based and/or weak KV storage vectors.
  63   For MIXED, this is required to avoid seeing raw bits.
  64 * Pinned objects can promote beyond gen0, but the page type remains
  65   as EDEN_type because it would take more computation to decide whether
  66   to turn a page into something different.
  67   Additionally it might not be possible to change because:
  68   - EDEN_BOXED can hold the union of ordinary BOXED and MIXED
  69   - EDEN_MIXED can hold the union of ordinary MIXED and UNBOXED
  70
  71 Caution: this writeup only applies to x86-64.
  72 Ensuring visibility of writes for relaxed-memory-order machines
  73 is an issue. Something can possibly be done involving sys_membarrier.