peter green wrote: > one thing i have heared (i don't use garbage collected languages much so > i've never seen this myself) is that the GC gets some CPU time and starts > causing stuff to be swapped in. This slows other threads down which gives > the GC more CPU and causes more stuff to be swapped in.
GC is started either when the system is (almost) idle, or when no more memory is available for some request. In the first case nothing is blocked by GC, and in the second case everything is blocked by out-of-memory, until the GC has collected free memory. > another effect that i have seen is when CPU usage is high a garbage > collected app can suck up all the systems memory. It can get all the memory > it needs for itself because it can force run its garbage collector when it > runs out but no other app on the system can. When GC runs in idle time, no other apps exist that could be blocked. When GC must swap something into memory, then the system is equipped with too little RAM for the current situation; in such a state everything runs slowly, due to permanent swapping. I know that people often discuss how to reduce swapping overhead, and typically they all miss the simple solution that they should extend their RAM to prevent swapping to occur at all. > some objects may use resources other than memory which are more valuable and > need to be freed asap. Destructors (or finalizers) can be called to release no longer required resources, even when GC is used. When it's known or suspected that an object could be destroyed, the GC can be invoked immediately. GC for itself doesn't eliminate all resource woes, of course. In special situations it may make sense to support GC with additional code, just like with any other memory management method (see below). > refcounting doesn't suffer from any of theese issues Reference counting has more critical problems, like zombie objects. GC will always find and remove all dead objects, whereas reference counting never can eliminate bidirectionally linked objects, as exist in a GUI (parent <-> child controls). > also note that use of const parameters can eliminate a huge amount of > refcounting overhead. I'm not sure about the real impact of "const". And even if the use of const parameters results in a significant runtime reduction, this only indicates that much more runtime could be saved by not using reference counting at all! DoDi _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
