Understanding Memory on iOS

Understanding Memory on iOS

 

 - What kind of memory?

• Physical/Resident Memory 

• Graphics Memory 

• Virtual Memory 

• Malloc Heap 

• Dirty Memory 

• Native Memory 

• Mono Heap

 

Physical Memory (RAM)

• The total amount of memory on-chip 

• You can’t have more*

          * But Android users can... until it is mysteriously gone

 

 

Virtual Memory (VM)

• iOS apps don’t work with Physical Memory directly, they work with Virtual Memory 

• App’s private address space 

• Divided into Pages (4KB or 16KB) 

• Pages are mapped to Physical Memory by the OS

 

Resident Memory

• An app can allocate a block of memory in Virtual Memory but not use it (”reserve”) 

• The app has to modify the allocated VM for the OS to map it to PM (”commit”) 

• Resident Memory is the total amount of Physical Memory used by the app at any moment

 

Clean Memory and Dirty Memory

• Clean Memory — read-only pages of Resident Memory which iOS can remove and reload 

• Dirty Memory — everything else in Resident Memory 

• Apps can share Clean Memory pages (like, system frameworks)

 

• Memory allocated for the following data is Clean (iOS can reload this from disk): 

        • App’s binaries, static code segments, 

        • memory-mapped files, 

        • System frameworks and dynamic libraries, etc.

 

Graphics Memory (VRAM)

• iOS uses a Unified Memory Architecture — GPU and CPU share Physical Memory 

• Graphics Driver allocates Virtual Memory for its resources 

• Most of this is Resident and Dirty

 

Malloc Heap

• A region of VM where the app can allocate memory using malloc and calloc functions 

• This is where Unity allocates all memory for its needs 

• The maximum size is unknown, but seems to be 2x Physical Memory

 

Swapped (compressed) Memory

• iOS doesn’t have a page file and can’t dump rarely used Virtual Memory pages to disk 

• But it can compress them and store in some other region of Physical Memory 

• SCM is a compressed part of the app’s Dirty Memory 

• The algorithm is unknown, but iOS usually tries to compress as much as it can

 

Native (Unity) Memory

• Unity is a C++ engine with a .NET Virtual Machine 

• Native Memory — part of Malloc Heap (VM Region) used for all Unity’s allocations 

• All asset data is in Native Memory, exposed to C# as lightweight wrappers

 

Native Plugins

• Native plugins do their own allocations in Malloc Heap 

• Their code binaries are “Clean”

 

Mono Heap

• A part of Native Memory allocated for the needs of the .NET Virtual Machine 

• Contains all managed C# allocations, maintained by Garbage Collector

 

 

Mono Heap

• Mono Heap    is not a large contiguous region of Native Memory 

• It is allocated in blocks to store objects of similar size 

• There can be allocated, committed but unused blocks 

• If a block is still unused after 8 Garbage Collection passes, its Physical Memory will be returned to the system (decommitted)

 

iOS Memory Management

• iOS is a multitasking OS 

• Each app works with its own Virtual Memory address space mapped to Physical Memory

• When the amount of free Physical Memory gets low, iOS starts trying to reduce memory pressure: 

        1. Removes Clean Memory pages (they can be safely reloaded later) 

        2. If the app takes too much Dirty Memory, iOS sends memory warnings 

        3. If the app fails to free resources, iOS terminates it 

• We don’t know the details about this algorithm 

• Sometimes an app can allocate more, sometimes less

 

Minimize the Size of Dirty Memory!

• Measure the app’s Dirty Memory and see if it grows over time, 

• Reduce the amount of objects contributing to Dirty Memory, 

• Note: some data can be compressed better.

 

• Reasonable limits of Dirty Memory: 

        • 180Mb for 512Mb devices, 

        • 360Mb for 1Gb devices, 

        • 1.2Gb for 2Gb devices. 

• ... but, iOS can still kill the app  

Tools

Unity Profiler | Simple View

• Mono (used) — the size of Mono Heap (the total sum of pink and green blocks) 

• Mono (total) — the total committed memory for Mono Heap (the total size of pink, green and blue blocks) 

• GfxDriver — the total size of 2D textures, excluding render targets 

• FMOD — the total size of memory requested by FMOD (audio) 

• Other values should be ignored: 

        • Total doesn’t include the size of game binaries, libs, frameworks, native plugins 

        • GfxDriver doesn’t include a lot of other allocations done by the Graphics Driver 

        • The Profiler only sees allocations done by Unity code

 

 

Unity Profiler | Detailed View

• Shows named objects in Native Memory and which objects reference them 

• Assets folder shows how much Native Memory assets take

             • Many large sounds

             • Probably duplicated textures (have identical names)

 

 

 

MemoryProfiler | BitBucket

• Shows a combination of: 

        • Assets (Virtual Memory), 

        • Assets (GPU) 

        • Managed objects (Mono), 

• Object references 

• Easy to see relative sizes

               https://bitbucket.org/Unity-Technologies/memoryprofiler

 

MemoryProfiler Extension | Github

• We can see Mono Heap 

• Total size: 256KB + 256KB + 128KB = 640KB 

• Used: 86.5KB.

               https://github.com/robertoardila/support-unity-memoryprofiler

   

 

Xcode Debug View

• Available in Xcode Debug Navigator view 

• Shows if the app is doing OK memory wise 

• Seems to be approximately Dirty Memory + Swapped Memory 

• For detailed profiling should use Instruments

 

 

VM Tracker Instrument

1. Total memory consumption: 

a. The app has allocated 1GB of VM 

b. It has committed 351MB (186+165) 

c. But iOS has swapped 165MB 

d. Now it is 186MB Physical Memory 

e. 118MB of which is Dirty Memory

 

2. Binaries, libs and frameworks 

a. They take Resident Memory 

b. But they are not Dirty (i.e., Clean)

 

1. *All* — all allocations 

2. *Dirty* — all Dirty allocations 

3. IOKit — Graphics Driver 

4. VM_ALLOCATE — Mono allocations + Heap

5. MALLOC_* — Malloc Heap 

6. __TEXT + __LINKEDIT — app and lib binaries 

7. __DATA — writable executable data 

8. Perf. tool data — Instruments overhead

 

Allocations Instrument

 

Example | Parsing JSON

1. Load and parse a 350KB JSON file 

2. GC.Collect() 

3. 8x GC.Collect()

iPhone 6, iOS 11.3 

Unity 2018.1

 

 

Step 0: Initial State

Different tools showing the same data: 

1. Unity Profiler shows 0.5MB committed but 364KB used 

2. VM Tracker shows 1.25MB of allocations (in 3 blocks), 0.5MB of which is Mono Heap 

3. Allocations Instrument shows each separate allocation (note the Category) Unity Profiler

 

Allocations Instrument shows call stack for all allocations: 

1. The first 4 allocations were done during IL2CPP initialization 

2. The 5th allocation was done when creating a managed object

 

• Two blocks of Mono Heap 

• Total size of Managed objects: 58KB 

• Notice the fragmentation

 

Step 1: Parsing JSON

1. Notice how expensive the operation was 

2. Total memory allocated during the process: 5.6MB 

3. But Mono Heap size hasn’t increased that much 

4. Because GC has run a few times to reclaim it

 

• Allocations Instrument shows new allocations 

• The same allocated blocks can be seen in VM Tracker 

• Notice that allocations (2) and (3) are in the same block 

• Mono Heap takes ~4MB of Virtual Memory, all of it is Dirty

 

 

Step 2: GC.Collect()

1. Mono Heap size, was: 3.0MB, now: 2.0MB 

2. Allocated Mono memory — no change 

3. Virtual Machine still has the same amount of committed memory 

4. Some of it is compressed

 

 

Step 3: GC.Collect() x8

1. 8x GC.Collect() calls is expensive 

2. Unity Profiler shows that the reserved Mono Heap size has decreased

 

Step 3: GC.Collect() x8

1. Two committed blocks were released 

2. They still reserve Virtual Memory but don’t contribute to Resident Memory

Understanding Memory on iOS  :            http://bit.ly/ios-memory