Well, FWIW I happen to have an iPad Pro sitting next to me, so I just whipped
up the following test and was able to allocate and write to almost 3GB of RAM
before it started crashing on me.
#define allocationSize (1024ULL*1024ULL*3050ULL)
#define stride (4096)
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
printf("Starting memory test...\n");
printf("Allocating memory...\n");
uint8_t *buffer=malloc(allocationSize);
printf("Writing to buffer...\n");
for(uint64_t cursor=0; cursor<allocationSize; cursor+=stride)
buffer[cursor]=0xAC;
printf("Done!\n");
return YES;
}
> On Dec 9, 2015, at 5:56 PM, Rick Mann <[email protected]> wrote:
>
>
>> On Dec 9, 2015, at 17:37 , Jens Alfke <[email protected]> wrote:
>>
>>
>>> On Dec 9, 2015, at 5:17 PM, Rick Mann <[email protected]> wrote:
>>>
>>> - By "virtual memory," I'm sure you don't mean it's swapping to disk
>>> (flash). Or do you? If not, how is it virtual?
>>
>> All memory is virtual in any modern OS — the only thing that sees ‘real’
>> memory addresses is the kernel’s VM subsystem. ‘Virtual’ just means there’s
>> a layer of indirection between address space and RAM.
>>
>> On iOS it’s just that the address space normally allocated to apps (by
>> malloc, etc.) isn’t backed by a swap file. So it doesn’t get paged out, but
>> it’s also limited by the amount of physical RAM.
>
> Ah, yes, of course. Just the address translation is happening. Yeah, I need
> to know if the dirty limit has increased.
>
> Alternatively, if mmap-ed memory would actually live in RAM, but get around
> the dirty limit (assuming for the sake of argument that the user isn't
> running other apps), then we really could get more memory without a speed
> penalty via mmap().
>
>>
>> By “how much virtual memory you can use” I believe Rick means how much
>> _address space_.
>
> No, I need to know how much I can actually allocate and dirty.
>
>
> --
> Rick Mann
> [email protected]
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list ([email protected])
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com
>
> This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
