Re: Lock-free reference counting

Juha Nieminen <nospam@xxxxxxxxxxxxxx> wrote:

The only way 'a' would not have a pointer to the allocated object is
if f() nulled (or whatever) that pointer.

Huh? We're discussing code of the form

ptr<foo> a = ...;
f(a);
g();

However, if it does that, then the reference-counting smart pointer
(which 'a' is) would immediately delete the object in question when
f() does that.

You've gotten yourself in a muddle. We're comparing C++
reference-counting behaviour (which you describe accurately) with a
tracing garbage collector. The tracing GC will examine a root set
(registers, stack frames, and global (and thread-local) variables to
find out which objects are still live and which aren't. Note carefully
that a GC of this form operates on machine-level concepts (like
registers, stacks and so on), not language-level concepts (like scopes
and variable lifetimes).

Imagine an architecture in which functions are called by pushing
arguments on a stack, and the caller is responsible for both fixing up
the stack afterwards and saving any important values in registers.
(This shouldn't be difficult: i386 usually works like this.)

Therefore, when we write a call f(a), the compiler emits code to push a
onto the stack, and call f. It then fixes up the stack pointer (a
simple add). Any copy of a in registers was gone by the time f returns
(caller saves, remember?) and the stack pointer has now been nudged past
the copy of a on the stack. The compiler could have pushed a copy of a,
but it would be a waste, since it's not referred to again. Assuming
that a was the only reference to whatever object it referred to, there
just aren't any at all any more. The GC can therefore detect this and
reclaim the object at any time after f returns and the stack fixup is
done.

A GC engine has absolutely no way of knowing that "a is not used
anymore" if 'a' still has the pointer to the object inside it.

You're thinking at the wrong level of abstraction.

-- [mdw]
.

Relevant Pages

  • Re: Inspecting messages
    ... Lines 171-175 copies registers onto the stack so they can be restored to ... destination address in edi. ... the pointer before doing an interrupt. ... What happens is that some values are pullled of the stack and stored in ax ...
    (comp.os.minix)
  • Re: I feel stupid... "Invalid combination of opcode and operand", was, now is FORTH question
    ... TOS in ebx - top of stack - first stack element ... PSP in ebp - parameter stack pointer - pointer to stack, ... execute next at the end of their definition. ... High level Forth definitions merely organize the ...
    (comp.lang.asm.x86)
  • Re: Seeking info on wParam and lParam
    ... >> but I'd bet reading registers or popping values off the stack is still ... >> faster than resolving a FAR pointer. ... >allocated in the application's address space that is inefficient. ...
    (microsoft.public.vb.winapi)
  • Re: how do threads work?
    ... You don't save all registers in every ... One convention would be that all registers are call ... pointer onto the stack and copy the stack pointer to the ...
    (comp.os.linux.development.system)
  • Re: win32 call dword ptr [eax] help needed
    ... I am kind of unsure as to how one would tell if this is in the heap or the stack. ... Anyone got any good documents on overwriting the SEH in a multithreaded application? ... >vtable directly, you are overwriting a pointer to an object, may be ... >talking about reliability we should ponder all options, ...
    (Vuln-Dev)