Symbian3/SDK/Source/GUID-6D8460DF-8B0F-5249-B236-92ABE0E67A14.dita
changeset 0 89d6a7a84779
equal deleted inserted replaced
-1:000000000000 0:89d6a7a84779
       
     1 <?xml version="1.0" encoding="utf-8"?>
       
     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
       
     3 <!-- This component and the accompanying materials are made available under the terms of the License 
       
     4 "Eclipse Public License v1.0" which accompanies this distribution, 
       
     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
       
     6 <!-- Initial Contributors:
       
     7     Nokia Corporation - initial contribution.
       
     8 Contributors: 
       
     9 -->
       
    10 <!DOCTYPE concept
       
    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
       
    12 <concept id="GUID-6D8460DF-8B0F-5249-B236-92ABE0E67A14" xml:lang="en"><title>Memory
       
    13 Allocation Overview</title><shortdesc>Provides low-level functionality by which a Symbian platform process
       
    14 can access and manipulate memory areas.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    15 <section id="GUID-B6FA381B-2A42-4D5A-9511-DC634E8AF6C2"><title>Purpose</title> <p>Most client programs do not
       
    16 need to use this functionality directly. They are used by programs that are
       
    17 explicitly concerned about sharing memory areas between threads within a process,
       
    18 or between processes. </p> </section>
       
    19 <section id="GUID-39581657-1B46-436B-A8F2-A3F7AB525DA4"><title>Description</title> <p>The API has two key concepts: chunk
       
    20 and heap. </p> <p><b>Chunk</b> </p> <p>A
       
    21 chunk defines a contiguous region of virtual addresses. It represents memory
       
    22 that is addressable by running code. A chunk is the fundamental way in which
       
    23 Symbian platform allocates memory and makes it available to running code. </p> <p>The
       
    24 range of addressable memory is also referred to as <i>reserved</i> memory. </p> <p>Physical
       
    25 addresses representing either memory storage like RAM, or memory-mapped I/O
       
    26 devices, are mapped into a subset of a chunk's reserved memory. Such memory
       
    27 is said to be <i>committed</i>. </p> <p>When a process is created, it contains
       
    28 at least two chunks: </p> <ul>
       
    29 <li id="GUID-143BBF82-BAA5-5548-83AC-54DF2067C058"><p>a chunk that contains: </p> <ul>
       
    30 <li id="GUID-2A57D6BD-83FD-5C4B-B5AC-CA1BACDD5CB7"><p>the process executable's <codeph>.data</codeph> section
       
    31 (initialised global and writable static data) </p> </li>
       
    32 <li id="GUID-F6D7AB82-BEB5-5052-9723-B190F12A47ED"><p>the process executable's <codeph>.bss</codeph> section
       
    33 (zero filled data) </p> </li>
       
    34 <li id="GUID-DC6E22B6-9E12-5181-99DB-D6C2154C513A"><p>user-side stack space
       
    35 for all threads that run in that process. </p> </li>
       
    36 </ul> </li>
       
    37 <li id="GUID-73016FAD-8F84-596C-B048-CD1E1B05AA8B"><p>a chunk to contain the
       
    38 heap used by the main thread of the process. </p> </li>
       
    39 </ul> <p>If the process executable is loaded into RAM (i.e. it is not ROM
       
    40 resident), then there is another chunk to contain the code. </p> <p>On ARM
       
    41 processors up to and including those that support the ARMv5 architecture,
       
    42 the memory model used by Symbian platform is the <i>moving memory model</i>.
       
    43 To guarantee real-time behaviour using this model, each process is limited
       
    44 to a maximum of 16 chunks. This means that a program can create up to 14 additional
       
    45 chunks. Where the process executable is loaded into RAM, the chunk containing
       
    46 the code is effectively global and does not contribute to the 16 chunk per
       
    47 process limit. </p> <p>On ARM processors that support the ARMv6 architecture,
       
    48 the memory model used by Symbian platform is the <i>multiple memory model</i>.
       
    49 Using this model, there is no limit on the number of chunks per process. Where
       
    50 the process executable is loaded into RAM, the chunk containing the code is
       
    51 specific to the process. </p> <p> <xref href="GUID-DA41F070-0E54-3F8A-B301-39A0C6AFAB38.dita"><apiname>TFindChunk</apiname></xref> is used for
       
    52 finding a global chunk created by another process. </p> <p>The user-side interface
       
    53 to a chunk is provided by an instance of the <xref href="GUID-326A2F4D-0E99-31C0-A35D-E8BF45913F07.dita"><apiname>RChunk</apiname></xref> class. </p> <p><b>Heap</b> </p> <p>A heap is used for explicit dynamic allocation of memory.
       
    54 Symbian platform defines C++'s <codeph>new</codeph> operator to create objects
       
    55 on the current thread's heap. </p> <p>Heaps may be: </p> <ul>
       
    56 <li id="GUID-1ADAF0B8-BB72-5D07-BEA9-359DEFFC25E3"><p>monitored for memory
       
    57 leaks: this happens automatically for GUI applications </p> </li>
       
    58 <li id="GUID-0F5F3E02-F1E1-56D0-9865-D3DFA440DCF0"><p>shared between threads
       
    59 within a process </p> </li>
       
    60 <li id="GUID-ED409A70-ECD3-5EE9-9245-42FDEF5CCA42"><p>accessed and manipulated
       
    61 at the cell level </p> </li>
       
    62 </ul> <p>The heap interface is provided by the <xref href="GUID-9DB4A58C-6FC8-3292-A547-4C161BD188FC.dita"><apiname>RAllocator</apiname></xref> and <xref href="GUID-C5475104-B67A-3722-B11D-DBB930423492.dita"><apiname>MAllocator</apiname></xref> classes.
       
    63 This interface is abstract so that device manufacturers can implement heaps
       
    64 with different allocation algorithms. Symbian platform provides the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class
       
    65 as a default heap implementation. In practice, there is no need to know about
       
    66 implementation details. </p> <p>When managing the current thread's heap, it
       
    67 is more convenient to use the equivalent functions provided by the System
       
    68 Static Functions API; this is the <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita"><apiname>User</apiname></xref> class. For example, <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita#GUID-C197C9A7-EA05-3F24-9854-542E984C612D/GUID-C035F07D-B6D9-3A21-A323-DAC89137280D"><apiname>User::AllocL()</apiname></xref>.
       
    69 The System Static Functions API also provides macros that conveniently wrap
       
    70 calls for monitoring heap usage for memory leaks. </p> </section>
       
    71 <section id="GUID-7A3524D6-AA39-49A2-9DBC-E3EAEA654A7B"><title>See also</title> <p> <xref href="GUID-506642C2-A14F-55F2-9377-43DDB14F4053.dita">Raw
       
    72 Memory Overview</xref>  </p> <p> <xref href="GUID-FF8F5D97-7D37-5F6B-84A3-C064E2FD53E0.dita">System
       
    73 Static Functions Overview</xref>  </p> <p> <xref href="GUID-5D4B86D3-20C4-5D87-A6C1-225018D32347.dita">Thread
       
    74 And Process Management Overview</xref>  </p> </section>
       
    75 </conbody></concept>