Re: Lock-free reference counting

Juha Nieminen <nospam@xxxxxxxxxxxxxx> wrote:

Again, false. "a" is very well alive after the call to f(), and it
has internally a pointer to the allocated object. A GC won't destroy
that object as long as "a" is alive and well.

In fact it needn't be. In the absence of C++ destructor semantics, the
compiler would be free to remove any reference to `a' from registers (or
anywhere else) immediately, and indeed this may well be sensible, in
order to recycle the register for something more valuable.

As a practical matter, I've had a (Boehm--Demers--Weiser) collector free
up objects `prematurely' -- i.e., highlighting a bug where the
programmer failed to keep a reference alive for long enough.

But there's no fundamental reason why a GC /has/ to collect stuff early.
The primary abstraction that a GC provides is an illusion of unbounded
storage, and exactly how it decides to achieve that is its business.
(Of course, such characteristics may lead one to choose a particular GC
implementation or technique over others; I mean to say only that they're
not fundamental to the idea of GC.)

It's precisely because a GC has absolutely no notion of what the code
is doing that it can *not* collect that object. It sees a pointer
pointing to the object,

Why is there necessarily a pointer still?

Yes, and that's exactly why both PHP and Apple's Objective-C (eg. on
the iPhone) use reference counting for memory management?

Trying to argue that something is sensible because PHP does it is not
especially convincing! GCC's Objective-C implementation uses the BDW
collector, by the way.

-- [mdw]