3 ms·
> implementing a generational collector requires the ability to move things around in memory While this is true for traditional implementations with separate h
by dfox 10y ago
> implementing a generational collector requires the ability to move things around in memory
While this is true for traditional implementations with separate heap regions, it is not necessary. One can easily represent new and old generations as linked lists in per-object overhead and just change pointers in such overhead to move objects between generations. There is at least one Smalltalk VM that works in this way and IIRC traditional BEAM (ie. non-HiPE) Erlang VM has GC that works in essentially same way.
- eternalban 10y ago> One can easily represent new and old generations as linked lists Sure, it's easy but non-optimal. A side-effect of a moving generational garbage collector is heap compaction and better temporal locality.
- stevefolta 10y agoThe Boehm collector claims to be generational, and doesn't move memory, but I haven't found the details of its generationality.
- dfox 10y agoThe relevant paper describes it as "mostly-parallel, mostly-generational". The idea is that it works like traditional tri-color mark and sweep collector, but white objects stay white between partial collections unless they are modified (ie. reside on memory page that was modified and thus caused memory access trap). In essence it seems to me that difference between generational and incremental/parallel mode lies only in what causes white objects to revert to black (ie. if it happens after each sweep (incremental) or only when sweep does not produce enough free memory (generational)).