Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Got an Idea of GC. Please CC

Name: Anonymous 2014-05-27 0:07

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.

Name: Anonymous 2014-05-27 3:13

>>6
Shared-nothing greatly simplifies IPC for the user at least. It tends to be slower, but it's not that bad. You can use an ARC¹ for your shared objects need.
[1] http://doc.rust-lang.org/0.10/sync/struct.Arc.html

Maybe check out LVars. I don't know what a good collector would look like with LVars or if its even helpful, but at least determinism would be enforced. I suppose the resulting lattice would be huge.

>>8 is being a shit, but Rust would allow you to avoid GC most of the time without abandoning it entirely. You also don't do manual memory management the way you normally would. The extent to which you have to write lifetime annotations is fairly small, and when you do they're checked for correctness.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List