Or you could malloc the memory for the buffer (free'ing it when
you're done) and disable/enable collection on any objects pointers
you store in it that you also want to keep alive. Maybe that's
easier to understand.
(Any time you use disableCollectorForPointer is a possible leak, by
the way. The object will be rooted until you reenable collection,
so don't try to reenable collection from within the finalizer of an
object that the rooted object will keep alive. That's an
uncollectable cycle.)
-Ken
On Wed, Oct 15, 2008 at 4:45 PM, Ken Ferry <[EMAIL PROTECTED]> wrote:
> What I did try was
> 'NSPointerFunctionsStrongMemory|
NSPointerFunctionsObjectPointerPersonality'
> which does work even though some of the pointers aren't objects
and this
> doesn't seem quite correct but since I'm using GC
> NSPointerFunctionsObjectPointerPersonality seems nearly equivalent
to
> NSPointerFunctionsOpaquePersonality as long as description isn't
called.
I see.. I think it's a bug that NSPointerFunctionsStrongMemory|
NSPointerFunctionsOpaqueMemory is rejected.
It's probably not very future safe to add non-objects with the
object personality. You might prefer to use
NSAllocateCollectable(NSScannedOption) and forego the pointer
array. This allocates a chunk of memory that is:
(1) Collected by the collector when unreachable by strong reference
chain from a gc-root.
(2) Conservatively scanned.
To keep the memory alive when used as the void* contextInfo, you'd
still need to use -[NSGarbageCollector disableCollectorForPointer:].
The main gotcha is that any stores of gc objects into the buffer
need to generate write barriers, which are calls into the objective-
c library that let the collector know that the the buffer has
changed and needs to be rescanned next time a collection runs. This
should Just Work provided the type of the buffer is __strong, but
you can put doubt to rest by checking that the compiler emitted the
function calls. In Xcode, right click and choose "Show Assembly
Code", then look for the calls. For example, this
- (void)writeToCollectableMemory:(NSObject *)object {
int bufferLength = 5;
__strong void **buffer = (__strong
void**)NSAllocateCollectable(sizeof(void*)*bufferLength,
NSScannedOption);
buffer[3] = [[NSObject alloc] init];
…
compiles to this. objc_assign_strongCast is the function call.
"-[MyBlockOperation writeToCollectableMemory:]":
LFB672:
LM221:
LVL93:
pushl %ebp
LCFI337:
movl %esp, %ebp
LCFI338:
pushl %esi
LCFI339:
pushl %ebx
LCFI340:
subl $16, %esp
LCFI341:
call L245
"L00000000076$pb":
L245:
popl %ebx
LM222:
movl $1, 4(%esp)
movl $20, (%esp)
call _NSAllocateCollectable
movl %eax, %esi
LM223:
movl L_OBJC_SELECTOR_REFERENCES_3-"L00000000076$pb"(%ebx), %eax
movl %eax, 4(%esp)
movl L_OBJC_CLASS_REFERENCES_0-"L00000000076$pb"(%ebx), %eax
movl %eax, (%esp)
call _objc_msgSend
movl L_OBJC_SELECTOR_REFERENCES_4-"L00000000076$pb"(%ebx), %edx
movl %edx, 4(%esp)
movl %eax, (%esp)
call _objc_msgSend
leal 12(%esi), %edx
movl %edx, 4(%esp)
movl %eax, (%esp)
call _objc_assign_strongCast
…
-Ken
Cocoa Frameworks
On Wed, Oct 15, 2008 at 9:32 AM, Michael Link <[EMAIL PROTECTED]>
wrote:
> That makes sense, although
> 'NSPointerFunctionsStrongMemory|NSPointerFunctionsOpaqueMemory'
gives the
> error:
>
> *** -[NSPointerArray initWithOptions:] Requested configuration not
> supported.
>
> What I did try was
> 'NSPointerFunctionsStrongMemory|
NSPointerFunctionsObjectPointerPersonality'
> which does work even though some of the pointers aren't objects
and this
> doesn't seem quite correct but since I'm using GC
> NSPointerFunctionsObjectPointerPersonality seems nearly equivalent
to
> NSPointerFunctionsOpaquePersonality as long as description isn't
called.
>
> --
> Michael
>
> On Oct 15, 2008, at 1:08 AM, Ken Ferry wrote:
>
>> Hi Michael,
>>
>> NSPointerFunctionsStrongMemory|NSPointerFunctionsOpaqueMemory
doesn't
>> make sense. You're meant to specify only one of the memory
options and
>> only one of the personality options.
>>
>> Due to the way the bitfield work, your invocation is the same as
>> NSPointerFunctionsOpaqueMemory|NSPointerFunctionsOpaquePersonality.
>> This is the mode in which the pointer array is completely hands-
off.
>> It acts like a C array.
>>
>> Try NSPointerFunctionsStrongMemory|
NSPointerFunctionsOpaquePersonality.
>> That sounds right to me, though I get confused with the pointer
>> functions too.
>>
>> -Ken
>>
>> On Tue, Oct 14, 2008 at 9:43 PM, Michael Link <[EMAIL PROTECTED]>
wrote:
>>>
>>> I have a situation where I create an NSPointerArray on the stack
by:
>>>
>>> pointers = [NSPointerArray
>>>
>>> pointerArrayWithOptions:NSPointerFunctionsStrongMemory|
NSPointerFunctionsOpaqueMemory|NSPointerFunctionsOpaquePersonality];
>>>
>>> I then go about adding a few objects a selector and a pointer
>>> (contextInfo
>>> that could point to anything even a non-object) to the pointer
array.
>>>
>>> I then call:
>>>
>>> [[NSGarbageCollector defaultCollector]
>>> disableCollectorForPointer:pointers];
>>>
>>> The pointer array is then passed as the contextInfo for another
method
>>> (which turns out to be a weak reference), but isn't garbage
collected due
>>> to
>>> the previous call. The interesting part turns out that the
object at
>>> index 0
>>> (NSError* in this case) in the pointer array is garbage collected
>>> (probably
>>> because it was a variable in the function that called us). The
pointer
>>> array
>>> is configured to use strong references therefore index 0 isn't
set to
>>> NULL
>>> and something else is located at that memory (sometimes a
different
>>> object,
>>> sometimes garbage memory).
>>>
>>> If I use:
>>>
>>> [[NSGarbageCollector defaultCollector]
>>> disableCollectorForPointer:[pointers
>>> pointerAtIndex:0]];
>>>
>>> nothing bad happens and that object isn't collected.
>>>
>>> According to the documentation for disableCollectorForPointer:
shouldn't
>>> the
>>> pointer array be considered a new root object, and none of it's
pointers
>>> collected? Especially since it uses strong references?
>>>
>>> --
>>> Michael
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> 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:
>>> http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com
>>>
>>> This email sent to [EMAIL PROTECTED]
>>>
>>
>>
>
>
