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: Quincey Morris <email@hidden>
- Date: Tue, 19 Feb 2008 13:12:22 -0800
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.
_______________________________________________
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