Arc Forumnew | comments | leaders | submitlogin
1 point by stefano 6005 days ago | link | parent

> However I intend to use the same copy-algorithm for message passing

In this case, as you've already said, you can't overwrite the orginal type and you have to reserve extra space for the to-pointer (this means one extra word for every allocated object). This way another problem arises: you have to be sure that the to-pointer is clear every time you start a copy this is automatic after a GC, but not after a copy for message passing. This means that after every message passing, the whole heap must be scanned.

> Or maybe I should actually use a different routine for message passing and GC.

I think this is the best solution: passing a message and copying an object during garbage collection are enough different to make them distinct.



1 point by almkglor 6005 days ago | link

Yes, you're right. Looks like I'll end up having the message-passing use a std::map<> instead (which has O(log N) for each lookup, averaging O(N log N) for all memory areas involved in the message), and leave the to-pointers for the semispace destructor to determine which objects need to be cleaned up. Overhead either way.

Or again use a mark and sweep with copying instead of sharing of objects ^^. Well, not much different.

Memory management is hard. Let's go bytecoding!

-----