There seems to be some confusion as to what the 8GB limit under GC means. So,
a clarification
The 8GB limit is only on GC based allocations. That is, your app can allocate
up to 8GB of GC'd allocations, no more.
There is no such limit on the other allocation zones (the malloc zone, for
e
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
>> befor
On Dec 2, 2009, at 1:01 PM, Sean McBride wrote:
> 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. :(
Grab the source. It is just a constant.
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
On Dec 2, 2009, at 12:24 PM, Greg Parker wrote:
> The 64-bit garbage collector reserves a 32 GB heap and will not expand it
> further. If you allocate more than 32 GB you'll run out of memory.
Actually, it is an 8GB heap.
b.bum
___
Cocoa-dev mailing
On Dec 2, 2009, at 7:27 AM, Sean McBride wrote:
> 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
On Dec 2, 2009, at 7:27 AM, Sean McBride wrote:
> I'm stress testing a 64 bit GC app with AUTO_USE_GUARDS and left it
> running overnight. This morning it's crashed here:
>
> #00x7fff879390da in objc_exception_throw
> #10x7fff83c4a18e in _NSOutOfMemoryErrorHandler
> #20x7fff835046f9 i
On Wed, Dec 2, 2009 at 7:27 AM, Sean McBride wrote:
> How does a 64 bit app fail to allocate memory? For my process, Activity
> Monitor shows "real" at 2.2 GB and "Virtual" at 200 MB. My physical
> memory is not even exhausted.
64-bit apps can fail just like 32-bit apps; you could request an
am
