Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!polyslo!ttwang
From: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Newsgroups: comp.lang.c++
Subject: Re: Support for movable objects in C++
Message-ID: <1989Oct3.074446.14707@polyslo.CalPoly.EDU>
Date: 3 Oct 89 07:44:46 GMT
References: <1989Sep30.051559.20644@polyslo.CalPoly.EDU> <6590272@hplsla.HP.COM>
Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang)
Distribution: usa
Organization: Cal Poly State University -- San Luis Obispo
Lines: 52

jima@hplsla.HP.COM (Jim Adcock) writes:
>>/ hplsla:comp.lang.c++ / ttwang@polyslo.CalPoly.EDU (Thomas Wang) / 10:15 pm  Sep 29, 1989 /
>>There is a feature or mis-feature in C++ that makes building a copying
>>garbage collector difficult.  Copying garbage collector have two advantages
>>over non-copying garbage collector: (1) Copying garbage collector compacts
>>the heap automatically.  (2) Frequently used objects can be copied together
>>for better locality of reference.

>Essentially, this just strikes me as another call for using handles to objects,
>rather than just objects themselves.  If one believes that garbage collection
>is a central aspect of OOP, and that copying garbage collectors are the
>way to go, then one uses handles, and gets a language that looks like one
>of the many sons and daughters of Smalltalk.

The addition of 'volatile classes' would not cause C++ to become like
Smalltalk, since the user can use ordinary classes where it's appropriate.

>If one does not believe that GC is central to OOP, and that one is better
>off to try to avoid GC as much as possible, and that when one does GC
>one need not do copy collection -- then one does not use handles, and can make
>good use of the efficiency of C++ -- not requiring multiple indirection to
>do simple things.

It's just one extra indirection, which comes to about a few CPU cycles.
If C++ is just used as a better C, then GC is not required.  But if one
want to use C++ to build classes which can be re-used by different
modules, then GC and exception handling is required.  For example: one
normally passes a pointer to insert an object into a list.  When the list
is deleted the list class itself does not know if it's safe to destroy
the pointers it contains.  This is a quite common problem.

Beside copying garbage collection will let the program run faster.  Reduced
paging activity will easily offset the extra pointer indirection.

Heap fragmentation should not be treated lightly either.  Let the system
contains N bytes of free space, and S small objects in memory.  For a totally
fragmented system, the largest object size that can be allocated is
(N - S * small_object_size) / (S+1)
The largest object size that can be allocated in a heap compacted system is
(N - S * small_object_size)

>I don't believe copying and compacting are necessary in C++ where GC is
>typically a secondary concern.  Look again at Boehm's GC system and/or
>buddy systems.

Like I said, copying garbage collection will be an improvment.  In the main
while, non-copying garbage collection will have to do.

 -Thomas Wang (Ranma no baka!
                 - Ranma 1/2 )

                                                     ttwang@polyslo.calpoly.edu