[gclist] Re: gclist-digest V1 #42

[Drew Dean]

Re: Bob Duff's comment on GC is an implementation issue, not a
language issue

It's a language issue.  If your language requires dynamic memory
allocation, and has no free operator, then you'd better have a GC.
Most of the languages I'm familiar with (alas I'm at home and don't
have references at hand) that are intended to be GC'd have semantics
written for infinite memory, and the implementation is allowed to
implement the illusion of infinite memory however it likes.  Of
course, tracing collectors (or reference counting) are conserative
approximations of "will this value be used in the rest of the
computation?"

Certainly language definitions matter: if you can take the address of
a variable (even if you can't dereference the pointer), you can't use
a copying collector.  (Sun's java implementation will have to change a
little if they want a copying collectors, because the default
implementation of hashCode() is simply casting the object handle to an
int. A copying collector would break Java's hashtables at present.
But this is an implementation issue, because the language spec does
not define the implementation of hashCode().)

Drew Dean
ddean@cs.princeton.edu