Re: NSOperationQueue question
Re: NSOperationQueue question
- Subject: Re: NSOperationQueue question
- From: Tim Murison <email@hidden>
- Date: Fri, 07 Aug 2009 17:06:14 -0400
- Thread-topic: NSOperationQueue question
On 07/08/09 4:33 PM, "Quincey Morris" <email@hidden> wrote:
> On Aug 7, 2009, at 13:05, Tim Murison wrote:
>
>> In my real application I have a memory leak that I can trace to
>> operations
>> not being release by the operation queue. This program is meant to
>> show that
>> in the simplest way possible.
>
> I really don't think it shows that at all. If your analysis is
> correct, this code might show that you are able to outrun the
> collector by 1MB/sec, but that's about all.
Alright, I thought my sample was valid but I'll allow that it could be
better. Thus, the "improved" version, with a twist. If it is compiled with
objc-gc-only, then the [pool release] will cause an objc_collect_if_needed,
if compiled without GC, it is a old-style memory managed program.
#import <Cocoa/Cocoa.h>
#include <libkern/OSAtomic.h>
volatile int64_t globalCounter;
@interface Operation : NSOperation
+ (Operation*) operation;
@end
@implementation Operation
+ (Operation*) operation
{
return [[[Operation alloc] init] autorelease];
}
- (void) main
{
OSAtomicIncrement64(&globalCounter);
}
@end
int main(int argc, char **argv)
{
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
int64_t last, tmp;
last = tmp = 0;
[queue setMaxConcurrentOperationCount:4];
while (1) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int64_t tmp;
[queue addOperation:[Operation operation]];
tmp = globalCounter;
if (tmp - last > 1000) {
last = tmp;
printf("Queue length:%d\n", [[queue operations]
count]);
usleep(1000 * 1000);
}
[pool release];
}
}
With GC, the memory use grows forever, without GC, it doesn't grow at all.
Instruments tells me the garbage collector is responsible for allocating the
leaking memory from within the collection routine, I think maybe instruments
is confused, but it does confirm that the live object count grows without
bound. You can see a small dip when GC kicks in.
> If you're trying to demonstrate a leak, you'll have to bring the
> application (or at least the relevant section of code) back to a
> quiescent state before analyzing the memory usage. What happens if you
> stop creating operations after (say) 10 seconds? Is the questionable
> 10MB still in use a couple of seconds later, or did the memory usage
> drop back down? If it's still in use, you might well be able to use
> Instruments to find out what it is.
The improved code will execute about 1000 operations as quickly as possible,
then it will sleep for 1 second. Before sleeping, it will print the
operation queue length, proving that the queue doesn't grow for ever (it is
always < 5000 on my machine). Finally, the long sleep means that CPU use is
low giving GC plenty of time to do its work (even without the [pool drain]
hint.) Each iteration of the loop will attempt to collect the garbage.
> If you're trying to determine why there are so many threads, you're at
> least going to have to classify (or count) threads according to their
> status: waiting to execute, executing, finished executing. Large
> numbers of waiting or finished threads may be nothing more sinister
> than an artifact of your artificial test.
I'm not bothered by the threads other than that it seemed odd to create so
many of them and perhaps a symptom of the underlying problem.
***********************************************************************
This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s).
Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint.
Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses
destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint.
_______________________________________________
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