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:
Anonymous2014-05-27 0:14
if your hand is larger than your face
Name:
Anonymous2014-05-27 0:18
Cons: - Resolving cross-segment circular references would require compacting/collapsing cross-referenced data into single segment (which one has more references to the other).
Pros: - GC implementation will be forced to do compaction and memory defragmentation (especially useful with shared memory residing across several machines).
>>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.
>>10 In basically all of the languages with shared-nothing, serialization is automatic. In Rust the required trait can be derived by the compiler.
>>11 It's ugly, and will remain that way until/unless higher-kinded types arrive. That's probably not going to make it pretty for you, but it will for me. Go could be pretty as you like and it wouldn't help; it's not typesafe.
Rust isn't a C clone. It's more of a sweet spot between ML and C++.
Rust has to appeal to C++ programmers, hence the "less worse than C++" syntax. ML programmers don't need it, they can just use Haskell or whatever if they want the hottest shit.
>>14 Keep trying different combinations, eventually someone will get offended.
>>16 I've already been paid to write Rust. Only a few dozen people are being paid to write it today but it isn't even 1.0 yet. In 2-3 years we can talk about how well Rust is doing. It should see 1.0 later this year.
Name:
Anonymous2014-05-27 10:06
GC
Pros - It allows idiots and retards to do programming
Cons - It's shit - Idiots and retards can now be your coworkers
structured loops are too verbose. I'm always wrapping them inside of a macros like #define map(X,Xs,Body) ({ \ __typeof__(Xs) GENSYM(_map_Xs) = (Xs); \ __typeof__(GENSYM(_map_Xs)[0]) X; \ __typeof__(({Body;})) GENSYM(_map_Y); \ QVector<__typeof__(GENSYM(_map_Y))> GENSYM(_map_Ys); \ int GENSYM(_map_K); \ for(GENSYM(_map_K)=0; GENSYM(_map_K)<GENSYM(_map_Xs).size(); GENSYM(_map_K)++) { \ X = GENSYM(_map_Xs)[GENSYM(_map_K)]; \ GENSYM(_map_Ys).append(({Body;})); \ } \ GENSYM(_map_Ys); \ })
Name:
Anonymous2014-05-28 20:33
>>30 wtf this isn`t assembly class go back to 1980 LOL we have real languages now, high level ones, not that you`d be able to recognize one when you see it you assembler robot
Name:
Anonymous2014-05-28 21:51
>>32 Assembly will be relevant as long as machine code exists.
tfw no pauseless GC tfw GC defenders keep saying it can be done but refuse to tell you what GC algorithm works for this, they just try to intimidate you away from asking more by saying you have a lot to learn
GC fags are the worst: intellectually dishonest liars.