> So, it's useful for the case when you're sending an object to a process.
Yes, but it is in fact the only case where we copy objects anyway (even reading a global variable would be effectively sending the object in the global to the process in question)
> for extremely large messages...
#define N I don't know
if(msg.total_size() > N){
msg.share(process);
} else {
msg.copy(process);
}
I think this will end up having twice the overhead though: you need mechanisms to support both sharing with copy-on-write-and-if-receiver-already-has-it and copying.
Take note also that sending messages is recursive: we might be sending a list and thus end up sending several items.
> I would think that for small things copying is less expensive than keeping track of who has it, etc., just to avoid copying.
This was the justification in the Erlang BEAM and JAM machines to always copy.
Unless we make some special immutable types as mentioned above; then we could share those. Maybe I'm just prematurely optimizing, and should just give up on trying to find ways to avoid the copy. Life is much simpler just copying. :)
How about just starting with always-copy, and later when we have performance data, and experience using it, we can code exceptions? I don't know how easy it would be to code such exceptions, but it would be less likely to break if we didn't make these decisions without empirical evidence.
>twice the overhead...
I didn't think it would create any extra mechanisms, just a short circuit rule when deciding to copy or not. Rather than checking the ref counts each time the item is mutated or sent, if it is smaller than a certain amount, we know it was copied.
Now, maybe ref counts are faster than total_size(), but I don't know.
Certainly, always copying would avoid this whole overhead business. :)
