Paul Fuller <pgf### [at] optusnetcomau> wrote:
> 1)  On Garbage Collection, I regard this as a huge factor in favour of 
> C# and .Net.

  Garbage collection is not the Holy Grail of programming (nothing is).
And you have to know about its weaknesses. Certainly these weaknesses
may not be relevant in many cases, but in some cases they may be.

  Garbage collection basically means that all your objects are destroyed
with a delay (or, at least in Java, may not be destroyed at all; I don't
know how it works in C#). In many cases this doesn't matter. However, in
the cases where it does matter it can be a real problem.
  Sometimes it may be imperative that the destructor of the object be
called *immediately* when that object goes out of scope. Delaying that
destructor call may even cause a malfunction in the program (sometimes
even in situations which happen rarely and may not be caught in testing).
One good example of this is a destructor which closes an open file handle
the object has: The number of open file handles is often limited, and if
they are not closed after use, the program may run out of them.
  Manually closing the file handle when it's not needed anymore is not
any better then manual memory management: There's always the danger of
a leak. Functions may be exited at unexpected places, etc.

  So, basically, garbage collection takes care of memory management,
often at the cost of reducing the possibility of the user implementing
automatic management of resources other than memory. These resources may
be system resources, or resources in the program itself. GC seems to
completely disregard them.

  In a language like Java the only way you can manage such resources is
by manually freeing resources when they are not needed anymore. This is
a step back to the C memory (and other resources) management: Laborious
and error-prone.
  C# may be slightly better in this regard, though.

  Another problem with GC, which admittedly is often not very relevant,
but in some cases may be, is that GC is very detrimental with regard
to swapping.

  Suppose that you have made a program which just sits in the background
and waits for some task requests (like those background applications in
Windows which often put a small icon in the taskbar). This application
may have reserved a fair amount of memory for itself, but for a given
task it might only need a small part of this memory.

  Since this application is idle, if the system is running out of memory
the system will swap the memory used by this application to disk. If then
this small task is requested, only the memory actually needed for the
task will be swapped out of the disk. The rest will be kept in the swap.

  However, assume that the GC engine happens to be triggered during this
task. What happens? Since the GC engine scans the entire memory used by
the application, *all* of its reserved memory will be swapped from the disk.
If there's nothing to gargabe-collect, all this swapping would then be
completely useless.
  If the system was running low on memory to begin with, this can be
quite detrimental. The system may start swapping like mad, all for
absolutely no benefit.

  So the question is: If you are making such an application, can you
tell C# to *not* to use garbage collection? Is GC optional?

  One of the biggest problems I see with GC is that in most languages
it's not optional.

-- 
                                                          - Warp

Post a reply to this message