[gclist] gc concerns

[Mike Roberts]

first of all, thanks for all of your quick responses.

> -----Original Message-----
> From: Boehm, Hans [mailto:hans_boehm@hp.com]
> Sent: Wednesday, December 13, 2000 12:14 PM
> To: 'Mike Roberts'; Gclist
> Subject: RE: [gclist] gc concerns
>
> ...
> 1) Response time.  The client may be stopped for long enough that
> the pause
> becomes visible to the user.

the client is being done by a different team, so i know it won't be written
with gc (hopefully, they won't try to keep me from using it). if the time
spent in collection (stop-the-world) is small compared to the amount of time
between internet updates (2-3 times a second is our goal) from the server, i
don't think the client will see any noticeable pause.

> 2) Multiprocessor throughput.  Even if you perfectly parallelism the GC
> client, the garbage collector may make the application
> single-threaded for a
> significant fraction of the execution time.  If 1/5 of the cycles
> are spent
> in the single-threaded portion of the GC, you'll be ending half the
> wall-clock time in the GC on a 4 processor machine.

that's half the gc's wall-clock time in the single threaded portion. not
half the application's wall-clock time in the gc, right?

i am certainly willing to trade some speed for safety and convenience. if
the server doesn't perform, we can purchase a bigger server rather than hack
and redesign. therefore, the use of this type of gc doesn't scare me because
languages such as dylan, lisp, and smalltalk use it (i'm sure big servers
are already implemented in lisp and smalltalk and work well). is my thinking
sound?

> ...
> 1) Most modern computers are memory-poor in comparison to the processor
> speed.  Hence there is strong motivation to keep heap sizes down, and thus
> most applications run with heap sizes that are small enough that
> stop-the-world collections finish in a reasonable amount of time, and GC
> pause times are often not much of an issue.

we're looking at 2-4G of memory per system, more if necessary. the
processors are most likely to be pentium iii xeons. this server application
will be the only application running on each server.

> Whether or not scalability issues are an issue on 4 processors
> will depend on
> how much time your application will spend in the allocator/collector.  For
> allocation-intensive applications it probably will be an issue.

we haven't finished the design so we're not sure how allocation intensive it
will be. knowing this ahead of time will help us take this into account
during design.

> Both the Geodesic Systems and our collector will usually accommodate
> third-party malloc/free applications, especially if you arrange for the
> third party malloc calls to be redirected to the GC.  Geodesic has spent a
> lot more time making that work under Windows than we have.

i wasn't able to specifically find a garbage collection library from
geodesic on their web page. their literature seems to suggest that their
product is a runtime analysis tool, more like boundchecker or purify. does
anyone know is this because the literature is aimed at managers, or because
have they phased out their garbage collector as an external product
offering?