[gclist] why malloc/free instead of GC?
Basile STARYNKEVITCH
basile@starynkevitch.net
Tue, 18 Feb 2003 15:49:47 +0100
>>>>> "Charles" == Charles Fiterman <cef@geodesic.com> writes:
Charles> Consider a large online application with the following
Charles> common requirement. 90% of all requests will be filled
Charles> in one second. All requests will be filled in ten
Charles> seconds.
There are two meanings of large here :
1. application with a big memory requirement at runtime
2. application with a big amount of code
These 2 meanings are not related. Some applications (e.g. numerical
engineering) may be a small amount of code requiring a huge amount of
memory for data. And some programs have a huge amount of code
(e.g. lots of special case processing), but needs a small amount of
data memory to run.
Charles> If you don't want to crash you must have type safety and
Charles> that implies garbage collection of some sort. Large
Charles> applications are written by pools of programmers some of
Charles> whom are very bad.
Yes. The programmer's time is an increasingly expensive resouce.
Charles> If you have mark and sweep or moving collection at some
Charles> point your application will become so large that
Charles> collection time causes you to violate it no matter how
Charles> many CPU's you add. You must have a way to distribute
Charles> free operations and not run them all at once.
It seems to me that large (at least in meaning 2) applications exist
which
are coded in a GC-ed language (like Lisp, Smalltalk, Java, Ocaml, ....)
never spend more than a few consecutive seconds in garbage
collection (just because a few seconds in todays machine is a lot of
CPU time).
Of course I would suppose that the largest software is still coded in
(decades old) Cobol (or perhaps Fortran). I'm not sure it is easy to
maintain.
Since copying a hundred megabytes per second is realistic on today's
machines, I would believe that a full major garbage collection of a
gigabyte heap (which for me is a big heap) should require less than 10
seconds.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France