Re:Baby's First Garbage Collector
by jeffdavis on Monday December 09, 2013 @12:26PM
(#6875343)
"manual malloc/free are increasingly futile unless you're targeting embedded devices"
Or have any algorithm that uses a lot of memory, or if you want control over how much memory the algorithm uses at a time.
In the article (which is great, by the way), you can see that mark-and-sweep means scanning all of the active objects. This does not have great scalability properties. CPU gets faster, but memory gets larger, so matters won't improve over time.
GCs are great for processes that are tiny. As soon as you have a memory-hungry algorithm, it starts looking worse.
Also, as others have pointed out, manual memory management is not synonymous with malloc/free. There are many other choices available, and region-oriented allocators are often nice for algorithms that use a lot of memory. PostgreSQL internally uses "memory contexts" where you allocate objects with the same lifetime (e.g. transaction-local state) in the same context, and wipe it all at once.
Or have any algorithm that uses a lot of memory, or if you want control over how much memory the algorithm uses at a time.
In the article (which is great, by the way), you can see that mark-and-sweep means scanning all of the active objects. This does not have great scalability properties. CPU gets faster, but memory gets larger, so matters won't improve over time.
GCs are great for processes that are tiny. As soon as you have a memory-hungry algorithm, it starts looking worse.
Also, as others have pointed out, manual memory management is not synonymous with malloc/free. There are many other choices available, and region-oriented allocators are often nice for algorithms that use a lot of memory. PostgreSQL internally uses "memory contexts" where you allocate objects with the same lifetime (e.g. transaction-local state) in the same context, and wipe it all at once.