C++ Garbage Collecter

[Thierry Bravier <Thierry dot Bravier at dassault-aviation dot fr>]

gcc Digest 25 Aug 1999 17:11:10 -0000 Issue 352

C++ Garbage Collecter
	9471 by: Kevin Atkinson <kevinatk@home.com>
	9472 by: Jeffrey A Law <law@cygnus.com>
	9474 by: Per Bothner <per@bothner.com>

---

• To: law at cygnus dot com
• Subject: Re: C++ Garbage Collecter
• From: Kevin Atkinson <kevinatk at home dot com>
• Date: Wed, 25 Aug 1999 00:04:11 -0400
• CC: Brian Beuning <bbeuning at mindspring dot com>, gcc at gcc dot gnu dot org

Jeffrey A Law wrote:
> 
>   In message <37C34F21.95D56129@home.com>you write:
>   > Brian Beuning wrote:
>   >
>   > > We used the Boehm collector on my last project and it worked very
>   > > well for us.
>   >
>   > Does gcc optimizations cause any problems with the garbage collector?

> They certainly have the potential to cause problems with garbage collectors.

Then I guess the question is:  Does anyone have any plans on making gcc
garbage collector safe?

-- 
Kevin Atkinson
kevinatk@home.com
http://metalab.unc.edu/kevina/

---

---

• To: Kevin Atkinson <kevinatk at home dot com>
• Subject: Re: C++ Garbage Collecter
• From: Jeffrey A Law <law at cygnus dot com>
• Date: Tue, 24 Aug 1999 22:09:11 -0600
• cc: Brian Beuning <bbeuning at mindspring dot com>, gcc at gcc dot gnu dot org
• Reply-To: law at cygnus dot com

  In message <37C36B3B.DDAD6A0E@home.com>you write:
  > Then I guess the question is:  Does anyone have any plans on making gcc
  > garbage collector safe?
Yes, but no specifics yet.  This is driven by the ultimate desire to be able
to hook in a garbage collector into gcc itself.

jeff

---

---

• To: gcc at gcc dot gnu dot org
• Subject: Re: C++ Garbage Collecter
• From: Per Bothner <per at bothner dot com>
• Date: 24 Aug 1999 22:09:24 -0700

Jeffrey A Law <law@cygnus.com> writes:

>   > There are a couple of coding techniques that can cause trouble.
>   > 1. Only storing (only) a pointer to an object that is outside the object,
>   > 
>   > for example
>   >     char * alloc() {
>   >         char * x = (char *) malloc( 100 );
>   >         return x-10;
>   >     }
>   > then the calling code knows to add 10 before using it.  This is highly
>   > perverse code and not likely to be found in practice, but it would break
>   > the Boehm GC.
> Actually, compilers do this internally sometimes as it allows them to
> generate more efficient loop code.

I don't think these statements are very relevant.  Yes, the compiler
sometimes does such re-writing, but that is not a problem for a conservative
collectors as long as there is still a pointer somewhere that points to
the actual base of the object.  And either you have a newly allocated
object that will be passed to someone, or it was an existing object
that was passed from somewhere (as an argument).  In either case, you
would have a pointer to the base object somewhere.

There is one problem I can think of:  Allocating a temporary object
is only used *local* to a function:

        char *x = (char*) gcmalloc(100);
        ... do stuff with x ...
        /* at this point x is dead */

Here you are the risk that x might be prematurely collected.  The
work-around is easy:  Don't do that.  Instead, use non gc-managed
memory for objects only used internally in a single function:

        class malloced {
            void *p;
            malloced(void *ptr) { p = ptr; }
            ~malloced() { free(p); }
        }

        char *x = (char*) malloc(100);
        malloced(x);
        ... do stuff with x ...
        /* malloced's finalizer will free x. */

There is at least one example of this "bad" use of gc'd memory in libgjc,
in the calls to _Jv_AllocBytes in java/lang/natSystem.cc.  I argued
against using gc'd memory for such buffers, mainly as a matter of style.
But I think we here have another reason to avoid it.  (In the case
at hand in natSystem.cc, I think we are safe, because the buffer is
passed as an argument to getpwuid_r, and there is no arithmetic on
the pointer.)

In practice, you are much more likely to get hosed by other problems
(including compiler bugs) than having the optimizer screw up
conservative collection.  It is a theoretical problem, but my
impression is that it is not an issue in practice.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

---

---

• To: Per Bothner <per at bothner dot com>
• Subject: Bad C++ code (was Re: C++ Garbage Collecter)
• From: Kevin Atkinson <kevinatk at home dot com>
• Date: Wed, 25 Aug 1999 01:45:24 -0400
• CC: gcc at gcc dot gnu dot org

Per Bothner wrote:

 have a pointer to the base object somewhere.
> 
> There is one problem I can think of:  Allocating a temporary object
> is only used *local* to a function:
> 
>         char *x = (char*) gcmalloc(100);
>         ... do stuff with x ...
>         /* at this point x is dead */
> 
> Here you are the risk that x might be prematurely collected.  The
> work-around is easy:  Don't do that.  Instead, use non gc-managed
> memory for objects only used internally in a single function:
> 
>         class malloced {
>             void *p;
>             malloced(void *ptr) { p = ptr; }
>             ~malloced() { free(p); }
>         }
> 
>         char *x = (char*) malloc(100);
>         malloced(x);

except that malloced(x) will be deleted here (before the next line)
What you wanted to say was 
          malloced x0 = x;

>         ... do stuff with x ...
>         /* malloced's finalizer will free x. */

-- 
Kevin Atkinson
kevinatk@home.com
http://metalab.unc.edu/kevina/

---