Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> If you would free memory as soon as it's no longer used, it could lead to delays when freeing a large object graph.

A GC still has those same delays when freeing a large object graph (assuming that large object graph is in the tenured generation). They're just sometimes incrementalized or done in a background thread. Your malloc implementation could do that too. If this were actually much of a problem, batched deallocation APIs that work on a background thread could be easily added to (or layered on top of!) the popular modern mallocs.

> Also, a lot of performance can be gained be re-using frequently-allocated short-lived objects' memory, rather than freeing them without special treatment.

Your malloc is already doing this, if it's any good. free is usually implemented with a free list.



A GC still has those same delays when freeing a large object graph (assuming that large object graph is in the tenured generation). They're just sometimes incrementalized or done in a background thread. Your malloc implementation could do that too.

Of course, I was just making an argument against 'immediately deallocating is always the best strategy'. It's clear that malloc()/free() could implement the same behaviour.

free is usually implemented with a free list.

Sorry, I was a bit vague: I was referring to moving garbage collectors, where one of the motivations was to be more performant with a lot of short-lived objects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: