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.

>>51
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).

So yes, if the programmer is able to statically specify the lifetime extents whenever the compiler can't resolve them, that is manual memory management.

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.