General Problems for GC'ed Applications?

[Walter Bright]

Karen Lanrap wrote:
> I see three problems:
> 
> 1) The typical behaviour of a GC'ed application is to require more 
> and more main memory but not to need it.

No, that is not at all how GC works. The whole idea behind GC is to 
"collect" unneeded memory so it can be reused.

> Hence every GC'ed 
> application forces the OS to diminish the size of the system cache 
> held in main memory until the GC of the application kicks in.

This has nothing to do with the system cache. All the system cache is is 
the most recently accessed memory. Memory that is allocated, but not 
referenced, is flushed from the system cache.


> 2) If the available main memory is unsufficient for the true memory 
> requirements of the application and the OS provides virtual memory 
> by swapping out to secondary storage, every run of the GC forces 
> the OS to slowly swap back all data for this application from 
> secondary storage

What you're describing is called 'thrashing', and happens on any system 
where the sum of the applications running regularly access more memory 
than exists on the system, regardless of what kind of memory management 
system is used.

 > and runs of the GC occur frequently, because main
 > memory is tight.

This is incorrect, as GC keys off of virtual memory available, not main 
memory available.


> 3) If there is more than one GC'ed application running, those 
> applications compete for the available main memory.

No, they compete for virtual memory. The most recently accessed pages 
(4k resolution) are swapped into main memory.

> I see four risks:
> 
> a) from 1: The overall reaction of the system gets slower in favor 
> for the GC'ed application.

No - GC uses *virtual* address space, it doesn't use any more *physical* 
memory than any other app would. Remember, physical memory only gets 
actually used if the memory is referenced. Unused virtual memory, even 
if allocated, is not put in physical memory.

> 
> b) from 2: Projects decomposed into several subtasks may face 
> severe runtime problems when integrating the independent and 
> succesful tested modules.

I seriously doubt that, unless the subtasks all want all of memory, 
which seems like an extreme, highly unusual case.

> c) from 2 and b: The reduction of man time in the development and 
> maintenance phases for not being forced to avoid memory leaks may 
> be overly compensated by an increase of machine time by a factor of 
> 50 or more.

GC apps often run faster than the equivalent explicitly managed apps. 
Why? Because:
1) GC apps need to do far less allocation
2) GC apps don't consume memory needed for <shared_ptr> or equivalent 
memory management objects
3) GC apps don't need to spend time doing synchronization of reference 
counts

> Therefore GC'ed applications currently seem to be suitable only if 
> they are running single instance on a machine well equipped with 
> main memory and no other GC'ed applications are used.

GC is quite mainstream now, and the technology has progressed far beyond 
such a primitive state. I believe your concerns are unfounded. I suggest 
the book "Garbage Collection" you can get from 
www.digitalmars.com/bibliography.html.