[gclist] Question from a newbie

[Jerrold Leichter]

| > In practice "data which is not reachable" begs the question of what should
| > be  reachable!
| >
| > For example:
| > void m1() {
| > Object obj1 = ...;
| > Object obj2 = ...;
| >    m2();
| >   return obj2;
| > }
| >
| > void m2() {
| >   /* gc gets invoked */
| > }
| >
| > When m2 is called an the gc is invoked is obj1 reachable?
| I'm not sending this to the list to prevent a flame war, but if I can
| pick a language to instantiate your program, let's consider C++, and
Well, actually you did :-)

| Object obj1 = new WaitCursor();
|
| relying on the destructor at the end of m1 to restore the normal
| cursor, which, oh by the way, keeps an "invisible" (at the source code
| level) reference around.
|
| I don't much like C++, but friends who use it praise this paradigm.
|
| I think we agree: the notion of what's garbage can get quite involved!
Any definition of garbage is inherently tied to the semantics of the program-
ming language.  In compiler terms, if a local variable is dead at a particular
point in the program, then its value can be safely collected at the point.
The definition of "dead" has to reflect the actual language semantics, however,
In C++, that semantics is quite explicit about the points at which destructors
for locals run.  In effect, there is some additional compiler-generated code
that invokes the destructor for obj1 at the point where it goes out of scope.
In deciding whether obj1 is dead, you must include that code - which means that
under a definition of garbage that is consistent with C++ semantics, obj1 is
not garbage until control flow leaves the scope in which it was declared.

(The C++ standard actually allows for the case of empty destructors, which
can be elided.  If Object has such a destructor, obj1 is indeed dead.  If you
want to be really fancy, you could generalize this to destructors with no
side-effects, though defining side-effect in this case would be quite
difficult - and ultimately pointless, since there's not much reason to write
a destructor with no side-effects to begin with!)

							-- Jerry