Re: Accessing buffers in NSData/NSMutableData under garbage collection
Re: Accessing buffers in NSData/NSMutableData under garbage collection
- Subject: Re: Accessing buffers in NSData/NSMutableData under garbage collection
- From: "Michael Ash" <email@hidden>
- Date: Tue, 19 Feb 2008 18:44:15 -0500
On Feb 19, 2008 4:12 PM, Quincey Morris <email@hidden> wrote:
>
> On Feb 19, 2008, at 11:03, Michael Ash wrote:
>
> > All local variables (variables stored on the stack and in registers)
> > are strong. Even the ones marked __weak. __weak (and __strong) only
> > apply for variables stored on the heap.
>
> I went back and read the documentation again. It's actually silent
> (unless I missed something somewhere) on the issue of whether the
> following local variables are strong or weak references:
>
> __weak id var1;
> __weak void* var2;
It is quite clear:
"The initial root set of objects is comprised of global variables,
stack variables, and objects with external references."
In other words, anything on the stack is strong.
> Certainly, 'id var1' is implicitly strong and 'void* var2' is not, but
> the document doesn't say whether "__weak" is either legal or dominant
> over the implicit attribute for a local variable.
This is not the case. When used to declare local variables, both "id
var1" and "void *var2" are strong.
What's more, even something like "int var3" is implicitly strong when
a local variable, although this one is an implementation detail you
shouldn't rely on.
> However, the point (that I originally missed) is that the answer
> doesn't matter. Local variables don't inhibit collection because
> they're strong, they inhibit collection of their referenced object/
> memory because it is in the garbage collector's root set.
That's really just another way of saying the same thing. You can think
of all local variables as being part of the root set (as the docs
describe it), or you can think of the stack itself as being part of
the root set, with all of its contents being strong references. They
are equivalent ways to describe the situation.
All of this should become clear when you think about how the collector
actually works inside. It needs to be able to track what references
what, and it needs to be able to zero out weak references when objects
they point to disappear. This is done by using read and write barriers
for anything on the heap. But for the stack, it doesn't use any
barriers. Instead it occasionally pauses threads to scan their stack
"manually" in an exhaustive fashion.
Since stack variables don't generate read/write barriers, they can't
be weak. Since no annotations are generated to describe the data types
of what's on the stack, everything is treated as strong, even integers
(and floats, and char arrays, and dead spaces not being used for
anything at the moment) containing the bit-patterns of pointers.
The stack and heap are two different universes with this GC system.
The heap relies on the compiler to understand types and to generate
read and write barriers as needed. The stack is a big formless blob
which is scanned exhaustively, and held in place during this process
by temporarily pausing the only code which is allowed to touch it. All
else flows from this.
(And don't forget that there's a third universe, the non-scanned,
non-collected heap, which you can get with malloc/free. The GC doesn't
touch it, but that very fact makes it interesting.)
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden