<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-592B6D20-4ABA-5C79-9734-D18E2CE4A86C" xml:lang="en"><title>Writable
Data Paging Overview</title><shortdesc>Overview of data paging, the next phase in Symbian's implementation
of demand paging. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-B1D8D3AD-4438-4C51-B900-1DD2B55202BC"><title>Purpose</title> <p>Writable
data paging allows the demand paging of any user-side data (for example thread
stacks and heaps). Writable data paging makes use of a fixed size backing
store to page out data. The backing store may use a NAND flash partition or
an embedded MMC (eMMC). </p> <p>The aim of data paging is to enable more memory-hungry
use cases without increasing the amount of physical RAM present in the device. </p> <p>For
example, data paging enables: </p> <ul>
<li id="GUID-F3B36258-F661-5562-A641-1875D33600B7"><p>running applications
that are not designed with the memory constraints of embedded devices in mind,
for example applications ported from other environments with writable data
paging (such as a PC). </p> </li>
<li id="GUID-7BB35E5C-6E38-50E6-B27E-094948F0F6A8"><p>running multiple applications
at the same time where previously there would not have been enough memory. </p> </li>
</ul> <p> <note> Data paging offers no performance increase, unlike code paging
which can speed up application loading by reading only the necessary pages
into RAM. </note></p> <p> </p> <p>However, writable data paging does have
the following limitations: </p> <ul>
<li id="GUID-EB2514D7-CE57-52F2-91D5-E790A41D12B2"><p>It is only possible
to page the following types of memory: </p> <ul>
<li id="GUID-9C9002DF-BF9B-5656-A57F-84C442E855B7"><p>user heaps, </p> </li>
<li id="GUID-8F6AC93B-F1BE-5CA6-899E-8433E2055013"><p>user thread stacks, </p> </li>
<li id="GUID-0EC7E799-24CC-590E-A67D-DAA014825A1E"><p>private chunks, </p> </li>
<li id="GUID-9789A61F-CB01-5AD8-8886-41CA74EA564F"><p>global chunks, </p> </li>
<li id="GUID-1C8479BE-B4E6-5E6D-83C0-D23E8DC6F9CF"><p>static data. </p> </li>
</ul> </li>
<li id="GUID-E11A66FB-C2DF-5DE7-B074-0CBDFC7EBE6D"><p>A single memory object
(e.g. a heap, stack, DLL or chunk) is the smallest granularity at which paging
can be configured </p> </li>
<li id="GUID-06F9012E-85CE-587C-B0E9-6BF7EE37A39F"><p>No attempt will be made
to page kernel-side data </p> </li>
<li id="GUID-88EE2287-EF50-5B7C-B63E-C2D172A1EA80"><p>No attempt will be made
to implement memory mapped files (e.g. posix's mmap) </p> </li>
<li id="GUID-C79316F5-BFF4-569E-8D44-AF5BDCBD0811"><p>No attempt will be made
to implement any kind of paging on the emulator. </p> </li>
</ul> </section>
<section id="GUID-9E27B27E-898B-43DA-8614-4AAEEE0A294E"><title>Required background</title> <p>This
document assumes that the reader is familiar with the concept of <xref href="GUID-F123D574-44DE-528A-806C-DB64229BCEA2.dita">Demand
Paging</xref>, and the existing implementation of ROM and code paging in Symbian
platform. </p> </section>
<section id="GUID-1028A9E3-C9D7-4A4B-9DD4-B719475D09E5"><title>Key concepts
and terms</title> <dl>
<dlentry>
<dt>Page</dt>
<dd><p>Memory is managed in fixed size units called pages. The size of a page
is usually determined by the hardware, and for ARM architectures this is 4K. </p> </dd>
</dlentry>
<dlentry>
<dt>Paged in or Paged out</dt>
<dd><p>If a given page of memory is present in RAM it is said to be <i>paged
in</i> (or just 'present'), as opposed to <i>paged out</i>. </p> </dd>
</dlentry>
<dlentry>
<dt>Paging in</dt>
<dd><p>The process of moving a page of memory from being paged out to being
paged in. </p> </dd>
</dlentry>
<dlentry>
<dt>Paging out</dt>
<dd><p>The process of moving a page of memory from being paged in to being
paged out. </p> </dd>
</dlentry>
<dlentry>
<dt>backing store</dt>
<dd><p>The external media used to hold <i>paged out</i> pages is referred
to as the <i>swap area</i>. This area may be much larger than physical RAM,
although a factor of around twice as large is considered normal in existing
systems. </p> </dd>
</dlentry>
<dlentry>
<dt>Working set</dt>
<dd><p>The term <i>working set</i> is defined as the memory accessed during
a given time period. </p> </dd>
</dlentry>
<dlentry>
<dt>Pinning</dt>
<dd><p> <i>Pinning</i> pages refers to paging in demand-paged memory and forcing
it to remain in RAM until it is <i>unpinned</i> at a later time. </p> </dd>
</dlentry>
</dl> </section>
<section id="GUID-AED67EBB-6176-4357-BC22-4A0B4E518265"><title>Classes</title> <p>The
following classes are affected by the use of writable data demand paging: </p> <p>The
following classes are involved in the use of threads and processes: </p> <table id="GUID-24779260-DE34-5184-9A58-560F06F0DE9D">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<tbody>
<row>
<entry><p>Class </p> </entry>
<entry><p>Description </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita"><apiname>RThread</apiname></xref>  </p> </entry>
<entry><p>This class is used to handle threads. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-9DD1EA2B-DC59-315C-8E9C-CE6D9461B695.dita"><apiname>RProcess</apiname></xref>  </p> </entry>
<entry><p>This class is used to handle processes. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-1D0D14AD-43CF-3B52-AD8D-641F75B8098C.dita"><apiname>TThreadCreateInfo</apiname></xref>  </p> </entry>
<entry><p>Used to specify the attributes of a new thread. </p> </entry>
</row>
</tbody>
</tgroup>
</table> <p>These classes are used in handling memory: </p> <table id="GUID-ACCA6C7E-92B5-51BE-B86E-D94E9FB0FF9F">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<tbody>
<row>
<entry><p>Class </p> </entry>
<entry><p>Description </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-326A2F4D-0E99-31C0-A35D-E8BF45913F07.dita"><apiname>RChunk</apiname></xref>  </p> </entry>
<entry><p>Handle a chunk. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-51F7DBCF-BFB6-31F9-8882-5D263A1AD4B4.dita"><apiname>TChunkCreateInfo</apiname></xref>  </p> </entry>
<entry><p>A structure that specifies the type and properties of the chunk
that is to be created. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-3DCB92FB-9C74-3B73-B229-BF7944087EE9.dita"><apiname>TChunkHeapCreateInfo</apiname></xref>  </p> </entry>
<entry><p>A structure that specifies the type and properties of a chunk with
a heap within it. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-C5D0C7E7-061F-3BA5-AE24-B83237684B01.dita"><apiname>UserHeap</apiname></xref>  </p> </entry>
<entry><p>A set of functions that are used to create heaps. </p> </entry>
</row>
</tbody>
</tgroup>
</table> <p>The following classes are used in client/server communication: </p> <table id="GUID-E823BA5C-620C-5B58-9945-8135EF7D39D1">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<tbody>
<row>
<entry><p>Class </p> </entry>
<entry><p>Description </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-8E316AC4-4676-301A-9A23-659E83AA1D1C.dita"><apiname>CServer2</apiname></xref>  </p> </entry>
<entry><p>The abstract base class for servers. </p> </entry>
</row>
<row>
<entry><p> <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref>  </p> </entry>
<entry><p>A client/server class that clients use to package arguments that
are to be sent to a sever. </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
</conbody><related-links>
<link href="GUID-9D66A168-AF11-51D9-903C-4A6C6D31DA3D.dita"><linktext>Flexible
Memory Model Overview</linktext></link>
</related-links></concept>