General Problems for GC'ed Applications?
Walter Bright
newshound at digitalmars.com
Thu Jul 27 13:55:23 PDT 2006
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.
More information about the Digitalmars-d
mailing list