Re: why malloc/free instead of GC?

Consider a large online application with the following common requirement. 
90% of all requests will be filled in one second. All requests will be 
filled in ten seconds.

If you don't want to crash you must have type safety and that implies 
garbage collection of some sort. Large applications are written by pools of 
programmers some of whom are very bad.

If you have mark and sweep or moving collection at some point your 
application will become so large that collection time causes you to violate 
it no matter how many CPU's you add. You must have a way to distribute free 
operations and not run them all at once.

If you make some restrictions on class structures and control collections 
centrally you can have reference counting and related methods that 
distribute frees. These are inefficient but we are supposing you can always 
add more CPU's. The great advantage of reference counting is that it is 
scaleable to very large sizes.

Reference counting also has the advantage that the destruction of objects 
can have rational finalizers. Finalizers must be safe, general, sure, 
prompt and ordered. Safe means they don't violate the type system. General 
means finalizers can run any code in the language and have that code 
produce normal results, for example exceptions can't just get discarded. 
Sure means if you build an object it gets to destroy itself. Prompt means 
finalizers aren't indefinitely postponed. Ordered means finalizers run in a 
determined order, if you ship the application you don't change the order 
creating portability bugs.