[gclist] ref-counting performance cost

[Stefan Monnier]

>>>>> "Simon" == Simon Peyton-Jones <simonpj@microsoft.com> writes:
> source of space.  As a result, allocation is typically done by an out-of-line
> call.   (Correct me if I'm wrong here.)

Only for heap-allocated objects.  C++ uses stack allocation rather heavily
and I expect Java compilers to make some effort at turning heap allocation into
stack allocation.
This is partly due to the fact that they presume heap allocation to be costly.

SML/NJ does the extreme opposite, but it also has its own costs.

>>>>> Greg Morrisett <jgm@cs.cornell.edu> writes:
> They have the added advantage of not requiring twice the space
> as a copying collector and thus can do roughly half as many collections.

This does not have to be the case with a copying collector.
The train algorithm is probably the most popular example.
With such algorithms, you only need the "space doubling" for one of the
partitions of your memory.  This can then be compared to the wastage
due to fragmentation.


        Stefan