Group: comp.lang.c++
From: Jon Harrop
Date: Tuesday, April 08, 2008 4:46 PM
Subject: Re: Thread-safe reference counts.

Chris Thomasson wrote:
> Without some compiler support, I don't see how Boehm GC could legally
> collect the live_pointer variable during the five minute pause.:
>
> {
> void* const live_pointer = GC_MALLOC(1024);
> sleep(60 * 5);
> }
>
>
> I have never used Boehm GC, but I might play around with it and see if I
> can blow it up... ;^)
>
> This is basically analogous to your scoped example; agreed? BTW, you can
> check to see if OCaml and/or .NET gets information from the compiler that
> could tell them that the live_pointer variable is not used after the sleep
> statement? I want to see if you can get a GC to print the words dead on
> the screen; here is some pseudo-code that you can convert to your lang of
> choice:
> ____________________________________________________
> struct object {
> ~object() { std::puts("DEAD!"); }
> };
>
> void foo() {
> object* live_pointer(new object);
> sleep(60 * 5);
> live_pointer = NULL;
> }
> ____________________________________________________
>
> Can you post your converted program? The only way the word DEAD could be
> printed on the screed within 5 minutes is if the compiler helped the GC
> out...

What you're calling "live_pointer" in your first example is just a variable
in scope and that does *not* imply a live pointer at run time. Compilers
will recognise that your "live_pointer" is dead code and will remove it.

In my example, compilers do recognise that the local variable "bar" on the
stack frame for the call to "f" dies before the call to "g" and compilers
do optimize away "bar" after it is known to be dead.

These ordinary optimizations are what allows the GCs to collect the value in
my example. They are not done for the GC and C++ compilers often already do
them. Hence it is likely that Boehm can also collect earlier than reference
counting on my example.

Finally, the GC needs to keep running and your call to sleep might stop it
(depending upon the specifics of the GC).

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Safety Articles | Usenet Groups | Usenet News | Bluegrass