Cast not your Perl before swine?

Levi Pearson levi at cold.org
Tue Dec 18 20:38:38 MST 2007


"Bryan Sant" <bryan.sant at gmail.com> writes:

> Java developers?  This is a feature of nearly all modern language
> runtimes.  The benefits of GC are obvious and the problem that it
> solves in a safe and consistent way is obvious.  There is debate about
> the actual runtime cost of some GC algorithms, but even if the costs
> were as expensive as suggested, GC is still worth it.  There's no
> reason to work your tightrope act without a net.
>
> Using automatic variables and virtual destructors is great, but there
> is plenty of room for error.

Garbage collection was invented for Lisp, primarily because it would
be remarkably inconvenient to program in it without it.  If you have
access to the ACM Digital Library, you can read the description of the
first garbage collection system here:
http://portal.acm.org/citation.cfm?id=367177.367199

As programming languages rise in their abstraction level towards a
Lisp-like level, garbage collection becomes more and more necessary,
since memory allocation often takes places behind the scenes.

In addition to the convenience factor, an important motivator behind
garbage collection in today's programming systems is security.  In
order for a programming language to be safe, it has to be able to
guarantee that data is always the type that it thinks it is.  In the
presence of manual heap memory management as is done in C and C++, it
is impossible to guarantee this.  E.g., if a pointer exists to a
variable of type foo, and that variable is freed, the space may be
reused by a variable of type bar, making the type of the pointer
invalid.  Imagine if the pointer was a function pointer, and the data
written into the new variable the address of some malicious code.

                --Levi



More information about the PLUG mailing list