Previous blog posts have discussed the Metro style application model using Windows Runtime. An important attribute of this app model is that apps are suspended when they are no longer visible to the user. Suspending Metro style apps in the background is a good thing, as it conserves CPU for other apps and ensures that background apps dont cause activity that can consume resources, thereby improving the battery life and increasing responsiveness. This is outlined in detail in Sharif Farag and Ben Srours blog post, all[/i] the memory that suspended Metro style apps would otherwise hold onto. Windows 8 can reclaim this memory without having to terminate an app.
<video width="480" height="270" controls="controls" poster="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43/3036.Reclaiming-memory-from-Metro-style-apps.jpg"><source src="http://ak.channel9.msdn.com/ch9/5c2b/1b9a4ea2-6cec-4869-a068-c5a49a3a5c2b/ReclaimingmemfromMetroApps.mp4" />Your browser doesn't support HTML5 video. </video>
Download this video to view it in your favorite media player:
[url=http://ak.channel9.msdn.com/ch9/5c2b/1b9a4ea2-6cec-4869-a068-c5a49a3a5c2b/ReclaimingmemfromMetroApps_high.mp4">High quality MP4</a> | [url=http://ak.channel9.msdn.com/ch9/5c2b/1b9a4ea2-6cec-4869-a068-c5a49a3a5c2b/ReclaimingmemfromMetroApps.mp4">Lower quality MP4</a>
[size=5]Memory, responsiveness, and Metro style apps[/size]
For any type of app (Metro style or desktop), Windows tries to regulate physical memory allocations on behalf of that app, regardless of the memory requests it has made. Windows has always behaved this way to keep memory available in anticipation of future app memory needs. Windows is careful to only allocate physical memory to an app when the app tries to touch it, even if the app had allocated it earlier. Windows will also page out or repurpose parts of memory from an app if the pages of memory havent been touched in a long time.
It is important to understand the goal is not to deny memory to a requesting process, but to delay allocating physical memory as long as possible (until the user actually touches the app) because as with many resources, there is a tendency for software to over-budget. The OS is the place where all these requests come together and it has the information to see that meeting all the fully budgeted requests would ultimately starve every process. Not only would work not complete, but the system will essentially lock up. This happens even if the memory is virtualinstead of running out of RAM, your PC would simply swap pages in and out of disk.
The physical memory given to a process at any point in time is referred to as the working set of the process. A private working set represents physical memory that is unique to a process. Processes also touch other pages of physical memory that are shared, which several processes can reference. When you look at the Processes view in Task Manager, the memory for a specific process is actually its current private working set. NOTE: For simplicity, when I refer to working set in this blog, I mean private working set.
When the system starts to run low on available memory, the OS will look in all processes for pages of physical memory that it can repurpose to satisfy other needs in the system, even by paging out memory when necessary. For desktop apps, Windows will try to keep the most important (frequently accessed) pages of memory in the apps working set this is because desktop apps expect to be able to run code at any time, even when theyre in the background. Its a fine balance though: if too many pages of memory were to be removed from a desktop app, it could affect the apps responsiveness due to additional disk I/O (as the app tries to touch memory that has been paged to disk under the covers).
For a deep dive on Windows memory management, see Mark Russinovichs Mysteries of Windows Memory Management Revealed talks: [url=http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL405" target="_blank">part 1</a> & [url=http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL406" target="_blank">part 2</a>.
Metro style apps, however, are different from desktop apps, in that they are usually suspended whenever they are no longer in the foreground. When theyre suspended, they arent touching ANY of their memory.
To illustrate, Ive highlighted a few suspended Metro style apps with memory held in their working sets in the screenshot below.
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0640.11_5F00_35FC5125.png" target="_blank"><img width="667" height="500" title="Suspended apps holding on to memory" style="border: 0px currentcolor display: inline background-image: none" alt="Task Manager, Processes tab, showing 11 suspended apps, using from 63.3MB to 3.8MB of memory, each" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6013.11_5F00_thumb_5F00_4ABE23D8.png" border="0" /></a>
[b]Suspended apps holding on to memory[/b]
NOTE: In the Consumer Preview build, the Suspended status does not show
in the Processes view of Task Manager by default you have to choose to show it
via an option on the View menu.
If there isnt memory pressure in a system, its actually a good thing (most efficient) to just leave memory in the suspended apps working sets. But if there is some memory pressure, the fact that these Metro style apps are suspended presents an opportunity to get almost all the memory in these working sets back for other apps, without terminating them.
Reclaiming memory from suspended Metro style apps
In Windows 8 Consumer Preview, we can efficiently write the whole (private) working set of a suspended Metro style app to disk, in order to gain additional memory when the system detects pressure.
This process is analogous to hibernating a specific app, and then resuming it when the user switches back to the app. Were taking advantage of the suspend/resume mechanism of Metro style apps to empty or re-populate an apps working set.
The sequence of events is described below:
- The Process Lifetime Manager (PLM) detects memory pressure in the system and asks the Memory Manager (MM) to empty the working set of a specific process that houses a suspended Metro style app.
[list]
- MM moves the pages of memory from the working set of the app to the operating systems modified page list (which is a list of memory whose contents are to be written out to disk before being reused).
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3288.Visio2_5F00_086B0B95.png" target="_blank"><img width="686" height="326" title="MM moves memory pages to Modified Page List" style="border: 0px currentcolor display: inline background-image: none" alt="Before: moving the memory pages for suspended app to Modified Page List, working set is 40.3 MB. After moving, the working set is 0.7 MB, and modified page list has new items in list. " src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3782.Visio2_5F00_thumb_5F00_442AA448.png" border="0" /></a>
[list]
- The working set pages on the modified page list are written out asynchronously, as dictated by the usual MM policies (written out opportunistically in the background, writes triggered when under memory pressure).
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4762.Visio3_5F00_35EC2B58.png" target="_blank"><img width="273" height="236" title="MM writes to disk asynchronously" style="border: 0px currentcolor display: inline background-image: none" alt="Modified Page List shown with arrow to disk, writing pages to disk asynchronously" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4375.Visio3_5F00_thumb_5F00_63011826.png" border="0" /></a>
[list]
- Even after the suspended apps working set is written to disk, the memory pages removed from a process are left intact on the operating systems standby list. This is a cache of useful pages of memory that can be repurposed for other apps, if necessary. If these pages are immediately needed again by their original process, they are quickly moved back.
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4760.Visio4_5F00_6D523C86.png" target="_blank"><img width="392" height="316" title="Pages written to Modified Page List are also on Standby List" style="border: 0px currentcolor display: inline background-image: none" alt="Pages shown in both Modified Page List and Standby List" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3201.Visio4_5F00_thumb_5F00_7A4C1C97.png" border="0" /></a>
If a user switches back to the app while its working set pages are still in physical memory (on the modified page list or the standby list), its straightforward: the pages will be added back into the apps process immediately. If they are no longer available, Windows will read in the apps working set from disk in an optimized manner.
[size=5]Reclaiming memory in action[/size]
To get a feel for how this works, lets walk through an example with real running code.
The initial state is represented by the screenshot above. I had several Metro style apps running on a PC with 2GB of RAM. The Metro style apps were in the background, and therefore Windows suspended them. I then started opening more apps to drive up memory use on the system and trigger the new functionality.
In the next screenshot, below, youll notice that I opened some apps in order to introduce additional memory pressure and induce the behavior described above. As you can see, Windows emptied the working sets of the suspended Metro style apps (highlighted).
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2318.12_5F00_7973B6AD.png" target="_blank"><img width="667" height="500" title="Working sets of Metro style apps emptied" style="border: 0px currentcolor display: inline background-image: none" alt="Processes tab of Task Manager, with all suspended apps using less than 1 MB of memory each." src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6428.12_5F00_thumb_5F00_573BAB27.png" border="0" /></a>
[b]Working sets of Metro style apps emptied[/b]
Lets compare the before and after working sets of the original Metro style apps (some of the after stats cannot be seen because Task Manager ran out of room to show all 27 launched apps):
<tbody>
Metro style app
Working set before (MB)
Working set after (MB)
Flixster
23.5
0.5
Flow
15.2
0.6
Kindle
23.1
0.5
LiveComm
3.8
0.3
Lyrics
65.3
0.9
Maps
28.1
0.8
Remote Desktop
21.0
0.5
SkyDrive
23.1
0.5
Store
26.9
0.6
Weather
42.0
0.8
Windows Reader
9.2
0.4
</tbody>
So in this example, we liberated over 250 MB of physical RAM for other apps to use without shutting down the suspended apps.
Responsiveness when reading the working set back in
A test for this new facility is how responsive a suspended app is after its working set contents are emptied and you decide to switch back to the app.
While I was running this test, I used the Lyrics app as my indicator of responsiveness. The Lyrics app can display the lyrics of a song as well as play back a music video. When the Lyrics app goes to the background, it gets suspended, which stops the playback.
After driving memory use to the point where working sets were emptied, I opened additional apps and used the system for a while to ensure that a swap back to the app was going to read the working set from disk. I then triggered the switch back to the Lyrics app (below).
[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6763.13_5F00_6EF2E28D.png" target="_blank"><img width="667" height="500" title="Lyrics apps working set is repopulated" style="border: 0px currentcolor display: inline background-image: none" alt="Processes tab of task manager, Lyrics app is now consuming 97.4MB of memory" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/1641.13_5F00_thumb_5F00_14102CFA.png" border="0" /></a>[/b]
Lyrics apps working set is repopulated
The key indicator I was looking for was how long it would take from the time I triggered the switch back to the app to the point where I could hear sound again. On a low-end machine, with a high memory load, its hard to perceive a difference in responsiveness when switching back to the app whose working set was being read from disk compared to when its working set was still in memory. Your mileage will vary though: the larger the working set, the longer it will take to read-in from disk. Were also continuing to reduce the amount we have to write to disk for Metro style apps and further optimizing this feature.
This functionality is something that everyone with the Consumer Preview release can try for themselves. Just open up a number of Metro style apps and desktop apps to generate some memory pressure, and then switch back to a suspended Metro style app that has had its working set emptied.
NOTE: Windows will still close Metro style apps if memory gets into the critical range. However, this feature will enable a system to run more applications before getting to that point.
Reading in a working set optimally
To have a responsive experience when you switch back to a suspended app whose working set is on disk, weve optimized how we write the working set in the first place, so that reading it in is as efficient as possible.
When we write out the working set of a suspended Metro style app, the working set pages are being written out to disk sequentially. This allows us to read the data back into a process using a small number of large sequential disk reads. The screenshot below is from our Windows Performance Analyzer (WPA) tool that comes as part of the [url=http://www.microsoft.com/download/en/details.aspx?id=28997" target="_blank">Assessment and Deployment Kit (ADK)</a>, showing a visual representation of disk reads during this process. Ive highlighted the working set read-in I/O. You can clearly see the sequential stream as we repopulate an apps working set.
[b][url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2727.Windows_2D00_Performance_2D00_Analyzer_5F00_437E9BC6.png" target="_blank"><img width="700" height="321" title="Windows Performance Analyzer" style="border: 0px currentcolor display: inline background-image: none" alt="Windows Performance Analyzer" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6763.Windows_2D00_Performance_2D00_Analyzer_5F00_thumb_5F00_02701C62.png" border="0" /></a>[/b]
Sequential read I/Os to repopulate an apps working set (WPA Tool)
Reading back sequential data from almost any storage device is really fast. Most rotational disks can achieve between 50-100MB per second. If a storage device is flash-based (like an SSD), you can get upwards of 200MB per second for these reads.
We expect that many apps will take less than a second of I/O to get the working set of a suspended app back into memory.
Conclusion
By definition, all PCs of all form factors have limited physical memory. The challenges of managing memory do not change when you add more physical memory, so long as you are actually running more programs that request more memory.
Several classes of modern software will continue to evolve to use more and more memory photo editing of giant RAW images, in-memory databases, very large spreadsheets, and so on. Whether these have WinRT-based implementations or desktop implementations, the OS needs to evolve to manage these ever-increasing memory requests. WinRT is an opportunity for programmers to use an API that allows access to all the memory they need while putting the user first in terms of responsiveness and getting work done. I hope youll try this out this feature in Windows 8 Consumer Preview.
-- Bill Karagounis
Source: [url=http://blogs.msdn.com/b/b8/archive/2012/04/17/reclaiming-memory-from-metro-style-apps.aspx]Windows 8 Blog
Last edited:
