[gclist] Re: gclist-digest V1 #66

[Mike Spertus]

This is an amendation I proposed to Bjarne Stroustrup's proposal for
gc in C++:

------------------------------------------------------------
Bjarne,

I read with interest your proposal for acknowledging that garbage collection
is possible for C++. I like the idea of a standard that endorses garbage 
collection as an option without trying to dictate its form. However, I
believe that your proposal requires some changes to avoid unnecessarily 
restricting the form of possible garbage collection implementations.

I would recommend making the following modification to the proposed working paper:
The last portion of the working paper text would become (starting after the end_comment before 
the definition of garbage collection):

===============================================

An implementation is called garbage collecting if it defines the macro
__COLLECTING as 1 in header <new>. Otherwise __COLLECTING is 0.

If an implementation is garbage collecting:

(A) Access to an object that has been unreachable at any point is implementation-
    defined.

(B) If an object has been unreachable at any point, it is implementation-defined
    whether its destructor will be called.

(C) It is implementation-defined whether delete releases memory.

===============================================

Comments:
1. The definition given in the working paper for garbage collection is far too restrictive
   and would probably exclude most existing garbage collectors. The memory of an unreachable 
   object may be used for many reasons, not just for another object. Many garbage collectors 
   simply unmap the memory to free up swap-space. This would not be covered by the "As-If" rule, 
   because a reconstructed pointer to a formerly unreachable object would still be a valid pointer 
   (possibly to a different object) if the memory was reused for a different object. I have suggested 
   above that an implementation be defined as garbage collecting if it makes use of (A), (B), or (C). 
   This is much less restrictive and moves the consideration to the standardized change
   in behavior.

2. The discussion of finalization should not insist on either option (1) or (2). After all,
   valid collectors choose many strategies for deciding which destructors
   are called. Most collectors call destructors under some circumstances.
   With compiler support, many classes of destructors could be safely called by
   the collector. I don't understand why the standard should make such a major
   decision. My modification was to make the calling of destructors implementation-defined
   in (B). This standards proposal shouldn't enmesh itself in deciding which finalization
   strategy collectors should follow.
   
3. In the commentary (but not in the working paper changes), you state that delete
   would call destructors but not free memory. Calling destructors is certainly correct,
   but it is too restrictive to specify that it would not free memory. Hybrid strategies
   are a very mainstream use of garbage collection. For example, an
   application that absolutely could not afford memory leaks would probably use both
   a conservative collector and manual freeing. It is too restrictive to require that
   the collector ignore commands to release memory in the program. On the other hand,
   sometimes it is good to ignore memory deallocation instructions to fix premature frees.
   Both choices should be compatible with __COLLECTING. Item (C) addresses this.

4. I'm not sure the __COLLECTING macro means anything. One of the 
   most popular uses of garbage collection seems to be to fix
   memory leaks in existing object libraries and programs. It is often not known at
   compile-time if the code will be run with garbage collection. So, a value of 0 
   for __COLLECTING can't ensure that it won't be linked to
   a collector. Furthermore, even standard malloc/free conforms with 
   defining __COLLECTING to be 1. Therefore, any value of __COLLECTING
   will probably comply with any implementation. 

   Even if __COLLECTING doesn't mean anything, it does accomplish your stated
   primary goal of providing legitimacy to the notion that garbage collection 
   can be useful for C++, so I think it's probably a good idea even if it accomplishes 
   more psychologically than technically.
   
   I would note that it may be possible to use the "as-if" rule to justify linking a 
   conservative collector to code that was compiled with __COLLECTING == 0.