Gecko [ www.utparral.edu.mx ]

Name	Size	Permission
figures	[ DIR ]	drwxr-xr-x
commandline.page	1.95 KB	-rw-r--r--
cpu-check.page	1.63 KB	-rw-r--r--
cpu-mem-normal.page	2.14 KB	-rw-r--r--
cpu-multicore.page	1.12 KB	-rw-r--r--
fs-device.page	1.53 KB	-rw-r--r--
fs-diskusage.page	2.14 KB	-rw-r--r--
fs-info.page	3.18 KB	-rw-r--r--
fs-showall.page	1.42 KB	-rw-r--r--
index.page	2.08 KB	-rw-r--r--
legal.xml	297 B	-rw-r--r--
mem-check.page	2.81 KB	-rw-r--r--
memory-map-use.page	6.06 KB	-rw-r--r--
memory-map-what.page	3.5 KB	-rw-r--r--
mem-swap.page	1.84 KB	-rw-r--r--
net-bits.page	1.39 KB	-rw-r--r--
process-explain.page	1.62 KB	-rw-r--r--
process-files.page	1.25 KB	-rw-r--r--
process-identify-file.page	1.84 KB	-rw-r--r--
process-identify-hog.page	2.09 KB	-rw-r--r--
process-kill.page	1.34 KB	-rw-r--r--
process-many.page	1011 B	-rw-r--r--
process-priority-change.page	2.87 KB	-rw-r--r--
process-priority-what.page	1.31 KB	-rw-r--r--
process-status.page	2.56 KB	-rw-r--r--
process-update-speed.page	1.64 KB	-rw-r--r--
solaris-mode.page	1.8 KB	-rw-r--r--
units.page	1.53 KB	-rw-r--r--

Code Editor : memory-map-use.page

<credit type="author copyright">
 <name>Phil Bull</name>
 <email>philbull@gmail.com</email>
 <years>2011</years>
 </credit>

<credit type="author copyright">
 <name>Michael Hill</name>
 <email>mdhillca@gmail.com</email>
 <years>2011, 2014</years>
 </credit>

<desc>View the memory map of a process.</desc>
 </info>

<title>Using memory maps</title>

<comment>
 <cite date="2011-06-18" href="mailto:philbull@gmail.com">Phil Bull</cite>
 Explain how to use the Memory Map feature.
 </comment>

<gui>Virtual memory</gui> is a representation of the combined
 <gui>physical memory</gui> and <link xref="mem-swap">swap space</link> in a
 system. It enables running processes to access more than the
 existing physical memory by <gui>mapping</gui> locations in physical memory
 to files on disk. When the system needs more pages of memory than are
 available, some of the existing pages will be paged out or written
 to the swap space.

The <gui>memory map</gui> displays the total virtual memory use of the
 process, and can be used to determine the memory cost of running a single or
 multiple instances of the program, to ensure the use of the correct shared
 libraries, to see the results of adjusting various performance tuning
 parameters the program may have, or to diagnose issues such as memory
 leaks.

To display the <link xref="memory-map-what">memory map</link> of a
 process:

<steps>
 <item>Click the <gui>Processes</gui> tab.</item>
 <item>Right click the desired process in the <gui>process list</gui>.</item>
 <item>Click <gui>Memory Maps</gui>.</item>
 </steps>

<section id="read">
 <title>Reading the memory map</title>

<list>
 <item>
 Addresses are displayed in hexadecimal (base 16).
 </item>
 <item>
 Sizes are displayed in <link xref="units">IEC binary
 prefixes</link>.
 </item>
 <item>
 At runtime the process can allocate more memory dynamically into an
 area called the heap, and store arguments and variables into
 another area called the stack.
 </item>
 <item>
 The program itself and each of the shared libraries has three entries
 each, one for the read-execute text segment, one for the read-write data
 segment and one for a read-only data segment. Both data segments need to
 be paged out at swap time.
 </item>
 </list>

<table shade="rows" ui:expanded="false">
<title>Properties</title>
 <tr>
	 <td>Filename</td>
	 <td>The location of a shared library that is currently used by the
 process. If this field is blank, the memory information in this row
 describes memory that is owned by the process whose name is displayed above
 the memory-map table.</td>
 </tr>
 <tr>
	 <td>VM Start</td>
	 <td>The address at which the memory segment begins. VM Start, VM End and
 VM Offset together specify the location on disk to which the shared library
 is mapped.</td>
 </tr>
 <tr>
	 <td>VM End</td>
	 <td>The address at which the memory segment ends.</td>
 </tr>
 <tr>
	 <td>VM Size</td>
	 <td>The size of the memory segment.</td>
 </tr>
 <tr>
	 <td>Flags</td>
	 <td>The following flags describe the different types of memory-segment
 access that the process can have:
 <terms>
 <item>
 <title><gui>p</gui></title>
 The memory segment is private to the process, and is not accessible
 to other processes.
 </item>
 <item>
 <title><gui>r</gui></title>
 The process has permission to read from the memory segment.
 </item>
 <item>
 <title><gui>s</gui></title>
 The memory segment is shared with other processes.
 </item>
 <item>
 <title><gui>w</gui></title>
 The process has permission to write into the memory segment.
 </item>
 <item>
 <title><gui>x</gui></title>
 The process has permission to execute instructions that are
 contained within the memory segment.
 </item>
 </terms>
 </td>
 </tr>
 <tr>
	 <td>VM Offset</td>
	 <td>The location of the address within the memory segment,
 measured from VM Start.</td>
 </tr>
 <tr>
	 <td>Private, Shared, Clean, Dirty</td>

 <td><list><item>private pages are accessed by one
 process</item>
 <item>shared pages can be accessed by more than
 one process</item>
 <item>clean pages have not yet been modified
 while in memory and can be discarded when designated to be swapped
 out</item>
 <item>dirty pages have been modified while in
 memory and must be written to disk when designated to be swapped
 out</item></list></td>
 </tr>
 <tr>
	 <td>Device</td>
	 <td>The major and minor numbers of the device on which the shared
 library filename is located. Together these specify a partition on the
 system.</td>
 </tr>
 <tr>
	 <td>Inode</td>
	 <td>The inode on the device from which the shared library location
 is loaded into memory. An inode is the structure the filesystem uses to
 store a file, and the number assigned to it is unique.</td>
 </tr>
</table>

</section>
</page>

${this.title}

Code Editor : memory-map-use.page