如何在Mac OS X上的64位处理中等大小的内存分配失败？ [英] How can a moderately sized memory allocation fail in a 64 bit process on Mac OS X?

问题描述

我建立一个照片书排版应用程序。该应用程序频繁DECOM presses JPEG图像到内存缓冲区的位图。的图像的大小被限制到100百万像素（而它们通常不超过15百万像素）。

I'm building a photo book layout application. The application frequently decompresses JPEG images into in-memory bitmap buffers. The size of the images is constrained to 100 megapixels (while they usually do not exceed 15 megapixels).

有时，这些缓冲区的内存分配失败： [[NSMutableData页头] initWithLength：] 返回零。这似乎发生在情况下，该系统的可用物理内存趋近于零。

Sometimes memory allocations for these buffers fail: [[NSMutableData alloc] initWithLength:] returns nil. This seems to happen in situations where the systems's free physical memory approaches zero.

我的<一个理解href="http://developer.apple.com/library/mac/#documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html%23//apple_ref/doc/uid/20001880-BCICIHAB">virtual在Mac OS X 记忆系统是在64位进程分配的实际上的（原文如此），不能失败。有16个艾字节的地址空间，其中我试图在同一时间最多为400兆字节分配。从理论上讲，我可以分配40个十亿这些缓冲区中没有击中的可用地址空间的硬限制。当然，实际的限制将prevent这种情况下作为交换空间被启动卷的大小限制。在现实中，我只是让极少数这些分配（少于10次）。

My understanding of the virtual memory system in Mac OS X was that an allocation in a 64 bit process virtually (sic) can't fail. There are 16 exabyte of address space of which I'm trying to allocate a maximum of 400 megabytes at a time. Theoretically I could allocate 40 billion of these buffers without hitting the hard limit of the available address space. Of course practical limits would prevent this scenario as swap space is constrained by the boot volume's size. In reality I'm only making very few of these allocations (less than ten).

我不明白的是，一个分配失败，无论多么低的物理内存是在该点的事实。我认为，只要有交换空间留给内存分配将不会失败（如网页，甚至没有映射在这一点）。

What I do not understand is the fact that an allocation fails, no matter how low physical memory is at that point. I thought that—as long as there's swap space left—memory allocation would not fail (as the pages are not even mapped at this point).

应用程序被垃圾收集。

编辑：

我有时间去远一点挖掘到这个问题，这里是我的发现：

I had time to dig into this problem a little further and here are my findings:

1. 在该问题只发生在一个垃圾收集的过程。
2. 当从 NSMutableData 分配失败，一个普通的的malloc 还是成功分配相同的内存量。
3. 在错误总是发生时，整个物理内存趋近于零（交换即将发生）。

1. The problem only occurs in a garbage collected process.
2. When the allocation from NSMutableData fails, a plain malloc still succeeds to allocate the same amount of memory.
3. The error always happens when overall physical memory approaches zero (swapping is about to take place).

我假设的NSData 使用 NSAllocateCollectable 来进行分配，而不是的malloc 垃圾收集下运行时。

I assume NSData uses NSAllocateCollectable to perform the allocation instead of malloc when running under garbage collection.

我的结论来自那就是收集无法分配内存的大块当物理内存不足。这再次，我不明白。

My conclusion from all that is that the collector is unable to allocate big chunks of memory when physical memory is low. Which again, I don't understand.

推荐答案

答案就在 libauto

随着OS X 10.6的8千兆的舞台被分配用于垃圾回收内存在64位平台上。这个舞台上减少了一半的大分配（> = 128K）和小（小于2048B）或中等（小于128K）的分配

As of OS X 10.6 an arena of 8 Gb is allocated for garbage collected memory on 64-bit platforms. This arena is cut in half for large allocations (>=128k) and small (<2048b) or medium (<128k) allocations.

所以，在10.6的效果，你有4GB的内存进行垃圾回收内存的大分配。在10.5竞技场具有 32Gb的的大小，但苹果降低了大小8G的上 10.6 。

So in effect on 10.6 you have 4Gb of memory available for large allocations of garbage collected memory. On 10.5 the arena had a size of 32Gb, but Apple lowered that size to 8Gb on 10.6.

这篇关于如何在Mac OS X上的64位处理中等大小的内存分配失败？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！