Re: Headless Cocoa/Java app - autorelease - solution ?
Re: Headless Cocoa/Java app - autorelease - solution ?
- Subject: Re: Headless Cocoa/Java app - autorelease - solution ?
- From: String Larson <email@hidden>
- Date: Tue, 3 May 2005 08:43:57 -0500
More vague docs on OSX/Cocoa/Java - NSPureApplication
<x-tad-bigger>public class Foo() extends NSPureApplication {
private doStuff(){
NSImage image = new NSImage(new URL("http://someplace..."));
// do stuff w/image.
return;
}
public static void main(String[] args){
NSApplication app = NSApplication.sharedApplication();
NSWindow dummy = new NSWindow();
NSGraphicsContext.currentContext().setImageInterpolation(NSGraphicsContext.ImageInterpolationHigh);
for(cnt = 0;cnt < 10; ++cnt){
doStuff();
}
Object o = new Object();
o.toString(); // place to set a breakpoint ;)
}
}
Using NSPureApplication, I get a large number of :
</x-tad-bigger><x-tad-bigger>2005-05-03 08:34:00.847 java[11408] *** _NSAutoreleaseNoPool(): Object 0x35f370 of class NSImageCacheView autoreleased with no pool in place - just leaking </x-tad-bigger><x-tad-bigger>
(2 per image instance to be exact) when the NSImage instance goes out of scope.
However, it seems that all the memory is reclaimed upon GC. Using the ActivityMonitor.app, I see both real and virtual memory end up ~where they started before entering the loop. Whereas not subclassing NSPureApplication, both the Real and virtual memory usage would just keep climbing until my system was choked.
So, while things *seem* to be working properly, I'm pretty spooked by the 'just leaking' messages.
Is there anyone from Apple listening ? Shed some light ?
Thanks.
</x-tad-bigger> _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden