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     gpar...@apple.com     Runtime Wrangler


_______________________________________________

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 arch...@mail-archive.com

Reply via email to