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 <rm...@latencyzero.com> wrote: > > >> On Dec 9, 2015, at 17:37 , Jens Alfke <j...@mooseyard.com> wrote: >> >> >>> On Dec 9, 2015, at 5:17 PM, Rick Mann <rm...@latencyzero.com> 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 > rm...@latencyzero.com > > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com > > This email sent to bdurb...@rattlesnakehillsoftworks.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com