Got an Idea of GC. Please CC

Segmenting GC:
- Partition heap into N segments;
- Give each segment a bitmap, keeping what memory cells the segment references;
- After collecting a segment, compare its resulting bitmap to the original, then free now unused objects (bits that went from 1 to 0, and which also have 0 in other segments).

Pros:
- Incremental;
- Parallelizable into N threads;
- Collected memory can be distributed across N machines (share your memory accross Internet);
- Each segment could be future partitioned into subsegments, which are collectible separately.

Cons:
- Write barrier required;
- Bitmap memory is proportional to N;
- Execution time is proportional to memory_size/N.

>>52

If the programmer has the freedom to decide when any object in non-stack memory is allocated and freed (including the choice between pass-by-ref and pass-by-value), then there is no forced GC (i.e. the memory management is manual).

Then could you please update your personal catchphrase to ``forced GC is shit''?

However, in practice there is another requirement: namely that there is no GC-related bookkeeping which hogs memory. E.g. if one allocates a linked list, there should be only one pointer that points to every node, not two or more.

I'm not sure that's fair. Even malloc has a pointer-sized overhead per allocation.