[fpc-devel] Modernising Pascal

[DrDiettrich]

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 alX-Mozilla-Status: 0009on Feb 28 03:54:03 2005
X-Mozilla-Status: 0801
X-Mozilla-Status2: 00000000
FCC: /D|/Programme/Netscape/Users/default/Mail/Sent
Message-ID: <422287CB.1E490BD3 at compuserve.de>
Date: Mon, 28 Feb 2005 03:54:03 +0100
From: DrDiettrich <drdiettrich at compuserve.de>
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0; html=0; linewidth=0
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: de,en
MIME-Version: 1.0
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Subject: Re: [fpc-devel] Modernising Pascal
References: <42189263.7080401 at blueyonder.co.uk>	<421BE243.D7F4231D at compuserve.de>
		<421DCDD2.7080004 at blueyonder.co.uk>
		<421FEE3D.98288A59 at compuserve.de> <4221AC34.40007 at blueyonder.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
dead objects.

> 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 X-Mozilla-Status: 0009has almost none of the problems which you described.

DoDi