[gclist] why malloc/free instead of GC?
Tue, 18 Feb 2003 08:27:55 -0600
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.