Re: libauto: what's "agc error: Can not allocate new region"
Re: libauto: what's "agc error: Can not allocate new region"
- Subject: Re: libauto: what's "agc error: Can not allocate new region"
- From: Greg Parker <email@hidden>
- Date: Wed, 2 Dec 2009 13:11:46 -0800
On Dec 2, 2009, at 1:01 PM, Sean McBride wrote:
> On 12/2/09 12:33 PM, Jens Alfke said:
>>> I'm stress testing a 64 bit GC app with AUTO_USE_GUARDS and left it
>>> running overnight. This morning it's crashed here:
>>
>> Doesn't that turn on GuardMalloc, which adds an extra unmapped page
>> before and after every allocation? In other words, there's an extra 8k
>> of address space used up by every single malloc call. This isn't going
>> to show up as RAM used by the process, because it's not mapped to
>> anything, but it certainly chews up address space in a hurry.
>
> Thanks to all for your replies.
>
> If GC memory is really limited to 8 GB (and not 32), then I probably am
> hitting that limit with the guard pages on. :( Is there a way to
> increase that limit, at least in debug? 8 is pretty puny. :(
That size is hardcoded into libauto.dylib. (And it is 8; I was trusting an incorrect comment that said 32.)
In theory, you can grab the open-source autozone project and build your own with a bigger size. In practice you might need to jump through some hoops to get it to build.
The heap size is in AutoConfiguration.h:
#if defined(__ppc64__) || defined(__x86_64__)
arena_size_log2 = 33ul, // 8G
> And Jens, AUTO_USE_GUARDS is the same principle as Guard Malloc, but
> they are not identical. As I understand it, the former applies to
> memory in the GC zone, the latter to the malloc zone. In my app anyway,
> AUTO_USE_GUARDS is slow, GuardMalloc is slower, and with them both on
> it's very slow indeed.
That's right. 64-bit AUTO_USE_GUARDS is faster because it allocates a big chunk of VM space and then changes permissions on small pieces of it. Guard Malloc actually allocates and deallocates the VM space every time, which is slower.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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