3 ms·
Multithreading also introduces issues for GC. It needs to stop all threads. If you look at how much work has been delivered towards the GC's of for example JVM,
by je42 10y ago
Multithreading also introduces issues for GC. It needs to stop all threads. If you look at how much work has been delivered towards the GC's of for example JVM, Go and V8. It is a really tough problem to get right for all application types.
Reference counting is very predictable. And if you see a bottle neck you can start fixing it.
And with ARC (Swift/ObjC) you get even compiler support to optimize all ref counting administration.
Further malloc doesn't have anything to do with ref counting as ref counting sits on top if it.
Further, GC languages also need to do book keeping: Generations and Compaction.
- lokedhs 10y agoThat is true, but only during GC itself. Refcounting causes these issues every time the reference is copied. For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.