[fpc-devel] Modernising Pascal
drdiettrich at compuserve.de
Mon Feb 28 03:54:03 CET 2005
Jamie McCracken wrote:
> The problem with GC is the lifetime of (dead) objects is significantly
> extended under GC. This means it hogs more memory for much longer.
> Memory allocation is also potentially slowed as a result of more objects
> remaining allocated on the heap so less chance of holes appearing which
> can be reused (unless you use a compacting GC).
Not using memory is a waste of resources. When memory becomes a precious
resource, e.g. when swapping may occur, GC may be called to recycle the
> GC runs in a seperate thread so will incur additional overhead from that
> too and you cant always predict when it runs and it can snare you at the
> most inappropriate times (EG if memory is in short supply the thread
> must become extremeley aggressive to avoid swap so you will lose
> performance big time in those cases and with compacting variety even
> more so if it does end up in swap)
IMO it doesn't make much sense to run GC in its own thread. This would
result in never ending GC, when the other threads continue to create
objects at the same time. If your observations on the runtime behaviour
of GC are based on such an implementation, I agree that this is a poor
and inappropriate GC implementation.
> > It's not the creation that costs GC time, instead it's the destruction
> > of the objects.
> Its potentially both. All GCs have a tradeoff between memory usage and
> performance. A compacting one may have faster allocation but uses more
> memory as a result. There is no perfect GC that both uses memory
> efficiently and gives good performance (when compared to manual).
Where do you see any difference between memory allocation in GC and in
any other memory manager? I can't see any difference. Every memory
manager must know where chunks of free memory exist, and which of these
chunks to use for a new object.
> There are over a dozen different GC strategies so some of my points
> apply to some but not others (same with a lot of the replies here) thats
> why this thread has become long and controversial - you simply cant make
> a lot of generalities without specifying which type of GC you are
> reffering to.
Some, IMO most, of the strategies can be dropped immediately, after
determination of their complexity. O(n^2) is inacceptable when O(n) is
achievable by other methods. I have experience only with mark/sweep GC,
which has almost none of the problems which you described.
More information about the fpc-devel