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.

>>50

I thought we'd reached a general consensus that GC is shit.

Far from it.

None of those problems would arise with "manual" memory management (which is actually quite automated yet allowing much more freedom and expressiveness to the programmer).

I got one question for you, you highly persistent and annoying individual. If a programming language implementation tries really hard to resolve allocation lifetime extents, and then for whatever is left unresolved either uses GC or (depending on a switch) asks the programmer to specify extents manually (or restructure the code to make it more obvious (to the analyzer)), would you qualify that language as ``GC'' or ``"manual" memory management''?