4 ms·

There's another difference: memory usage. For garbage collection, it's at the minimum only after a full GC (and there's a memory/performance tradeoff, in that u

by cesarb 7y ago

There's another difference: memory usage. For garbage collection, it's at the minimum only after a full GC (and there's a memory/performance tradeoff, in that using more memory allows doing less GC), while for reference counting, it's always at the minimum. Using more memory for the GC means less memory for other things like the disk cache (which caused a performance problem at work once, which we solved by giving the GC less memory to work with). (Also, "ownership transfer" can be free in reference counting, since the number of references is the same before and after so there's no need to modify the reference count. What isn't free is sharing ownership, since it needs reference count manipulation.)

lokedhs 7y ago
Indeed. Memory usage is a point I never addressed in my comment. When managing large Java applications, that is indeed one of the most important issues that one has to be aware of. Some runtimes tries to be more automatic than others, and there are books worth discussions to be had about that. As for the second paragraph, thank you for clarifying that. I used poor terminology. I should probable have said pointer sharing, or copying. For ownership transfer to be zero cost, the compiler have to be clever enough to figure out that the original reference isn't used after copy. This can be handled by the compiler itself, or be enforced by the language (as is the case with Rust, as far as I understand).
pjmlp 7y ago
That depends pretty much how the programming language allows for value types, stack allocation, global memory static allocation and off heap access, even in the presence of a GC.
sfink 7y ago
Ref counting uses additional memory to store the refcounts. And possibly more for the suspected set of the cycle collector. GC uses additional memory to amortize collections over allocations. (Zero overhead means constantly collecting, using 2x steady state memory size is not uncommon.) Overall, I think you're right, refcounting comes out ahead on memory usage. But it's not completely straightforward to determine.

by cesarb 7y ago

lokedhs 7y ago

Indeed. Memory usage is a point I never addressed in my comment. When managing large Java applications, that is indeed one of the most important issues that one has to be aware of. Some runtimes tries to be more automatic than others, and there are books worth discussions to be had about that. As for the second paragraph, thank you for clarifying that. I used poor terminology. I should probable have said pointer sharing, or copying. For ownership transfer to be zero cost, the compiler have to be clever enough to figure out that the original reference isn't used after copy. This can be handled by the compiler itself, or be enforced by the language (as is the case with Rust, as far as I understand).

pjmlp 7y ago

That depends pretty much how the programming language allows for value types, stack allocation, global memory static allocation and off heap access, even in the presence of a GC.

sfink 7y ago

Ref counting uses additional memory to store the refcounts. And possibly more for the suspected set of the cycle collector. GC uses additional memory to amortize collections over allocations. (Zero overhead means constantly collecting, using 2x steady state memory size is not uncommon.) Overall, I think you're right, refcounting comes out ahead on memory usage. But it's not completely straightforward to determine.