Re: Accessing buffers in NSData/NSMutableData under garbage collection

FROM : Quincey Morris
DATE : Tue Feb 19 22:12:22 2008

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;

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.

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.


On Feb 19, 2008, at 11:28, Alastair Houghton wrote:

> ...and globals...
>
> Anyway, the point is not to read too much into __strong or __weak. 
> They do what the documentation says, no more, no less.  It isn't a 
> good idea to invent all sorts of theories on the basis of "__strong 
> types" etcetera, because that isn't (presently) how things work.
>
> There's nothing wrong with pointer arithmetic on pointers returned 
> by NSAllocateCollectable(), it's just that you have to be careful 
> not to dispose of the pointer to the start of the block before 
> you're done with it.  Sadly, right now, that requires an awareness 
> of what the optimiser might do to your code.


I wasn't actually making the mistake of thinking that "__strong" is a 
type attribute. I was just trying to make the perhaps unimportant 
point that assigning an interior pointer to a non-interior pointer can 
be detected syntactically, which means there are 3 possible avenues 
for dealing with this case of optimization fragility, not just the 2 
you mentioned:

1. Enhance GC (code generation and runtime) to work with interior 
pointers.

2. Be careful not to let the non-interior pointer variable's lifetime 
expire before you're done with the interior pointer.

and

3. Enhance Objective-C -- to warn about or disallow certain patterns 
of interior pointer usage, say, or to generate code that preserves the 
base pointer reference when pointer arithmetic is used.