At 14:15 97/08/12, Philip Wadler wrote:
>> I think that Java might be slow, just because of this automatic garbage
>> collection.
>
>I can't let this chestnut go unchallenged. Let's not bandy about
>claims without evidence. GC is perfectly fine for building into phone
>switches (via Erlang) so it can't be all that slow. -- P
I am not an expert on the life and death of garbage collectors myself; I
got one of those get-it-off-your-garbage-collector letters in the mail. :-)
I think the main point is gaining programming speed, without sacrificing
so much running speed, that the programs cannot happen; right now at least.
But if you use a garbage collector running on a parallel thread in a true
multiprocessor environment not working at peak, then it could actually be
faster, I guess. Telecom applications, like handling dialups, where you
have a lot of processes which need no immediate cleanup might be the ideal
application.
But always having to use a garbage collector might get uneven
performance, I figure. For example, in airplane software, if your computer
want to do a cleanup in a critical moment of a landing, this would not be
so good.
Another concern might be control of a process; some processes may need to
be killed when they are not used anymore, and not at a later point. It
should then be a part of the object structure, and the programmer should
not have to write "kill".
If one uses C++ automatic variables with a reference count, then the
effect is the same as using a garbage collector (automatic variables are
stacked, so circular references should normally not happen). However, using
reference counts is slow. But, if hardware could learn how to handle
automatic references, this would not need to be so.
Anyway, I think one should not always be forced to use an automatic
garbage collector.
Hans Aberg
