Re:GC Tuning Confessions of a Performance Engineer
by pron on Saturday May 30, 2015 @01:47PM
(#9630991)
> I'm going to mention this too.
What I mean is that either those refs are permanent -- in which case they won't be traced -- or arbitrary -- in which case it's really more of an "arbitrary" problem than a "permanent" one.
> Object pooling is just a (limited, error-prone, poorly-performing) form of manual memory management.
... And reference counting is just a (limited, error-prone, poorly-performing) form of garbage collection.
> Contention isn't a problem if you don't touch the reference counts much. Cycles aren't a problem if you don't have cycles.
But now you've added restrictions that are much more onerous than those of object-pools.
In any case, my main question is this: if absolute top performance is what you need, why not have a GC + arenas (like RTSJ) without ref counting/manual management? In my opinion, there's only one downside to that approach is RAM footprint. If that's your answer, then I agree (I think that that's pretty much the main reson not to use a GC).
What I mean is that either those refs are permanent -- in which case they won't be traced -- or arbitrary -- in which case it's really more of an "arbitrary" problem than a "permanent" one.
> Object pooling is just a (limited, error-prone, poorly-performing) form of manual memory management.
... And reference counting is just a (limited, error-prone, poorly-performing) form of garbage collection.
> Contention isn't a problem if you don't touch the reference counts much. Cycles aren't a problem if you don't have cycles.
But now you've added restrictions that are much more onerous than those of object-pools.
In any case, my main question is this: if absolute top performance is what you need, why not have a GC + arenas (like RTSJ) without ref counting/manual management? In my opinion, there's only one downside to that approach is RAM footprint. If that's your answer, then I agree (I think that that's pretty much the main reson not to use a GC).