On Oct 24, 2008, at 8:52 PM, Mark Aufflick wrote:
I'm going mental here. I have an app, using garbage collection, that responds to distributed notifications. All the memory allocated by the method that responds to those notifications builds up (watching in top or Instruments) until a real UI event is recieved - click on a menu/window etc.
Yeah... that ain't right. But I'll need to know more about your app....
See below.
To try to flog the event loop into draining the pool I post an NSApplicationDefined event as per http://www.mikeash.com/?page=pyblog/more-fun-with-autorelease.html and other documents, but it doesn't clear the memory. I know the event is being posted because if I subclass NSApplication I can log the events being recieved in sendEvent: [NSApp postEvent:[NSEvent otherEventWithType:NSApplicationDefined location:NSZeroPoint modifierFlags:0 timestamp:0 windowNumber:0 context:nil subtype:0 data1:0 data2:0] atStart:YES]; Is there something special I need to do to have the garbaage collection collect inside a notification observer? If I let the application run overnight being fed regular notifications, the size gets over 100Mb of wasted memory, which I assume would be beyond the garbage collection threshold? Certainly any click on the app drops it down to 14Mb immediately.
OK.... "being fed regular notifications". Are the notifications being handled on the main thread? Are you running a runloop (I would imagine you would have to be to have the above work) in a standard fashion?
Any threads?Have you used the various tools on the system -- Object Graph in Instruments, malloc stack logging, malloc history, etc... -- to see what objects are hanging about?
--- On to possible reasons why. Given the lack of information, this is conjecture at the moment.(1) The further you move away from NSRunLoop, the more likely that you are running into artificial rooting caused by the stack. That is, the stack must be scanned conservatively because the compiler does not offer any way to know exactly where every object reference on the stack might reside. Thus, NSRunLoop will periodically clear the stack -- zero out the stack -- to eliminate any phantom references. It may be that you have created a situation where this clearing is not happening or is incomplete.
You can use objc_clear_stack() -- see /usr/include/objc/objc-auto.h -- to clear the stack.
See: http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcAPI.html#//apple_ref/doc/uid/TP40002467-SW14(2) However, given that the memory is building up over time, this indicates that something else is going on. That the memory is reaped when you trigger a UI event indicates that there is a collection class or something somewhere that is gathering together the memory over time. This seems unlikely, but possible.
To figure this one out, you'll really need to figure out what is hanging around that shouldn't.
If you do, please share. If you don't want to share ;), file a radar and send me the bug number -- at the very least, documenting the pitfall is warranted.
(3) I saved the simplest potential explanation for last.It might be that your program is just different enough from the well tested patterns that it fell through a collection crack. In particular, the collector interacts with the AppKit to such that the collector is effectively hinted as to when good times to collect might be. This hinting is pretty critical to the collector (for now -- the goal, of course, is to eliminate the need for any hinting while maximizing performance).
If you were to call [[NSGarbageCollector defaultCollector] collectIfNeeded]; at the end of processing notifications, that very likely might fix the issue.
If this is the case, filing a bug is warranted. If it is the case that a pure distributed notifications only application does not reap garbage, I want to know.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
