Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
- Subject: Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
- From: Rick Hoge <email@hidden>
- Date: Tue, 13 Nov 2007 21:07:51 -0500
Thanks for the reply -
On 13-Nov-07, at 7:10 PM, Nick Zitzmann wrote:
On Nov 13, 2007, at 3:30 PM, Rick Hoge wrote:
2007-11-13 17:11:06.686 MyApp[10413:10b] Here1
MyApp(10413,0x37cf60) malloc: *** mmap(size=788488192) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
2007-11-13 17:11:06.699 MyApp[10413:10b] Here2
This is what happens when memory allocation fails due to running out
of space. Remember, the maximum amount of RAM an application can
allocate in a 32-bit space is 4 GB.
Yes - the weird thing is that a malloc() of the exact same amount of
memory, at exactly the same place, has no problem.
I'm not surprised there's some performance difference between
malloc() and NSMutableData's convenience constructor, but I'm a
little surprised at how much. Also I'm trying to figure out why GC
leads to a failure, when the same code run non-GC does not. I
guess it's quite possible that the collector may not know in
advance that it's about to be hit with a huge memory demand, so
perhaps it's let a lot of garbage accumulate at the time of my
constructor...
When it's being run with GC, then something else is sticking around
in memory and is not being freed when it was previously expected to
be freed.
This sounds like the problem -
The experts will probably have something better to say here, but if
your application needs to allocate huge amounts of memory, then
maybe it'll be better off only using GC in 64-bit builds...
There is a certain irony in that many of our users don't put more than
2GB of RAM on their systems (due to cost I expect) whether it's a 32
bit or 64 bit CPU. I ran the above tests on a Mac Pro (65 bit Xeon)
with 16GB RAM and a 64 bit build and got the same failure.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
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