3 ms·

Objects aren't deallocated in garbage collected languages. The memory they had allocated just doesn't get copied to the new heap -- which is a big difference.

nostrademons 15y ago
You could argue that objects aren't deallocated in non-GC languages either, the memory they had allocated is just available for other objects to use. Which sounds kinda like "deallocated" to me, and yet it's the exact same thing as the allocation pointer in a stop & copy GC being free to overwrite them.
- spullara 15y ago
  Generally in other languages the memory is immediately freed and available to be reallocated. This is not true in most garbage collection strategies.
  - bunderbunder 15y ago
    Nor is it particularly desirable. One of the cornerstones of how a modern generational GC performs as well as it does is that blocks of objects are freed up all at once. If they were deallocated in a piecemeal fashion then: - Freeing up memory would take longer, because you can't just change a pointer back to the root of the generation. - Allocating memory would take longer, because it involves searching for a big enough empty slot rather than just throwing the new object on top of the heap. - More memory is wasted overall, because of heap fragmentation.
richdougherty 15y ago
That depends on the GC implementation. Maybe you're saying that because most modern collectors tend to generational collection, and copy between generation heaps. But copying is not required for GC. The trusty mark-and-sweep algorithm doesn't copy, for example. See: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Moving_vs._non-moving http://en.wikipedia.org/wiki/Garbage_collection_%28computer_...
- Someone 15y ago
  In fact, one can claim that mark-and-sweep is one of the few garbage collection algorithms that actually collect garbage. Many others collect non-garbage. Because there typically is way less non-garbage than garbage, that is what makes them competitive with alloc/free.
  - richdougherty 15y ago
    That's an interesting point, thanks.

nostrademons 15y ago

You could argue that objects aren't deallocated in non-GC languages either, the memory they had allocated is just available for other objects to use. Which sounds kinda like "deallocated" to me, and yet it's the exact same thing as the allocation pointer in a stop & copy GC being free to overwrite them.

spullara 15y ago
Generally in other languages the memory is immediately freed and available to be reallocated. This is not true in most garbage collection strategies.
- bunderbunder 15y ago
  Nor is it particularly desirable. One of the cornerstones of how a modern generational GC performs as well as it does is that blocks of objects are freed up all at once. If they were deallocated in a piecemeal fashion then: - Freeing up memory would take longer, because you can't just change a pointer back to the root of the generation. - Allocating memory would take longer, because it involves searching for a big enough empty slot rather than just throwing the new object on top of the heap. - More memory is wasted overall, because of heap fragmentation.

richdougherty 15y ago

That depends on the GC implementation. Maybe you're saying that because most modern collectors tend to generational collection, and copy between generation heaps. But copying is not required for GC. The trusty mark-and-sweep algorithm doesn't copy, for example. See: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Moving_vs._non-moving http://en.wikipedia.org/wiki/Garbage_collection_%28computer_...

Someone 15y ago
In fact, one can claim that mark-and-sweep is one of the few garbage collection algorithms that actually collect garbage. Many others collect non-garbage. Because there typically is way less non-garbage than garbage, that is what makes them competitive with alloc/free.
- richdougherty 15y ago
  That's an interesting point, thanks.