Re: why malloc/free instead of GC?

>>>>> "Charles" == Charles Fiterman <[email protected]> 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