The total physical memory of 3GB iOS devices is very tight. After system memory occupation, the available memory for third-party apps is extremely insufficient, leading to frequent OOM termination.
Enabling or disabling JavaScriptCore causes a huge difference in app memory crash threshold. Without JSC, the app will crash at only 1.52GB memory usage, which severely restricts normal business running.
The common 4MB and 8MB memory allocation used in our project falls into the high memory fragmentation range defined by libmalloc, resulting in the lowest memory crash limit and worst stability.
Our core business relies heavily on JSC environment for JS interaction, resource rendering and dynamic logic execution. We cannot shut down JSC, but 3GB devices still face serious memory shortage even with JSC enabled.
Mass users with 3GB RAM old iOS devices suffer from frequent app crashes, freeze, background kill and loading failure, which badly damage user experience and product reputation.
We have finished all app-level memory optimization: adjust allocation size, optimize memory release, reduce resident memory, but still cannot break through the fixed memory crash limit. There is no effective solution on application layer.
We sincerely ask Apple official engineers to provide official suggestions, system-level memory tuning solutions and JSC memory scheduling optimization guidance to solve the memory limit bottleneck on 3GB RAM iOS devices.
Memory Crash Test Table on 3GB RAM iOS Devices
What are the details of the test you’re actually running here?
If you're just calling malloc() without touching that new memory and then looping until you crash, then what you're hitting isn't any physical memory limit but is actually the address space. That would match up with the numbers you're posting, both because of the general limit "range" and because I believe linking against JavaScriptCore may cause the system to increase that limit. Note that this limit is specifically about address space, NOT actual memory use.
That leads to here:
Without JSC, the app will crash at only 1.52GB memory usage, which severely restricts normal business running.
Keep in mind that hitting the address space limit basically requires using address space algorithms or techniques like memory mapping large files. You can't really hit it with "standard" memory usage patterns (malloc-> touch-> free) because actual physical memory available is generally WELL below 1 GB, particularly in real-world conditions where other apps like VoIP or music playback have HIGHER priority than the foreground. In any case, my general advice is to avoid or limit these techniques, as large-scale usage tends to hit... exactly the limit you're seeing.
In terms of the specific "dip" at 8 & 4 MB, but the obvious solution would be to use your own allocator instead of malloc— either by sub-allocating out of large malloc allocations, or by directly allocating memory using a lower-level API like vm_allocate or mmap. Either approach would allow you to get closer to the other limits you've listed; however, no approach is going to let you go significantly beyond the limits you've found.
Kevin Elliott
DTS Engineer, CoreOS/Hardware