Let me help them with a definition for what we believe users and developers should expect from a “modern browser”:

• Modern browsers are fast. They take full advantage of the underlying platform to render graphics with the GPU, compile and execute JavaScript across multiple CPU cores and ensure that web applications run as close as possible to the same speed as native applications.
• Modern browsers enable rich, immersive experiences that could hitherto only be delivered through a plug-in or native application. They can blend video, vector and raster graphics, audio and text seamlessly without sacrificing performance.
• Modern browsers implement features when they are ready, providing predictable patterns that developers can rely on rather than suddenly breaking or removing specifications. They don’t check off support based on a half-completed implementation written to pass a synthetic test, but validate against a test suite that confirms interoperability.
• Modern browsers do adopt standards at an early stage of readiness so developers can experiment and validate the specification, but clearly delineate unstable prototypes as such.

It seems that others share this view. The discussion on YCombinator starts with this comment:

Maybe I'm just weird, but I consider issues like performance, reliability, and having a stable foundation to build on to be far more important than supporting your own browser's take on some hypothetical future "standard", which is just IE vs. Netscape all over again. On that basis, IE is currently the only one of the big three that is actually going in the right direction.

And Download Squad concludes its analysis of the Mozilla article with the following:

Don't get us wrong, [Firefox] is an excellent browser -- but more stuff doesn't necessarily equate to better stuff.

To our friends at Mozilla, we admire your passion for the open web, and we look forward to continued competition.

• A pure form of communication that is unsullied by cultural context;
• Broad adoption by as many as 10,000 speakers
• Independent (yet mostly compatible) dialects that not only bring additional choice for speakers also foster healthy competition and innovation

We expect even more communication between people in the coming year and are therefore focusing our investments in languages that are created based on constructed language principles. To that end, we are changing the spoken and written language of this nation to make it consistent with the form of speech already supported by the Language Creation Society. Specifically, we are supporting the Esperanto and Klingon languages, and will consider adding support for other high-quality constructed languages in the future. Though English plays an important role in speech today, as our goal is to enable open innovation, its further use as a form of communication in this country will be prohibited and our resources directed towards languages that are untainted by real-world usage.

These changes will occur in the next couple months but we are announcing them now to give citizens using other languages an opportunity to translate the libraries of the world into Esperanto.

Dankon, nedankinde!

One area they asked me to think about is how they can use social media effectively – a question that many charities and non-profit organizations wrestle with. And of course, it’s an area of great interest to evangelists like myself: an area that is a daily focus as we attempt to change perceptions of emerging technologies like IE9 and Silverlight.

So I thought I’d share a few thoughts here, both as a forcing function for me to distil a few ideas and hopefully as something that might be of interest to others.

1. Know what you’re trying to achieve. Too few organizations have a clear sense of the outcomes they hope to realize from engaging in social networks. What are your goals? Many organizations spend a lot of time encouraging supporters to ‘follow’ them on networks like Twitter and Facebook without much sense of why this is important or what they’ll do with these people once mobilized. This has a negative, rather than a positive effect – it diverts attention away from a core mission, and it leaves supporters with a premature feeling that they’ve ‘done their part’. Remember your core mission and be cautious about using followers as a proxy metric of success.
2. Know your audience. Assuming some measure of success, it’s important to have a clear sense of who you’re communicating with. In a non-profit setting, those who follow you on a social network are likely already your supporters. A familiar trap is organizations who fail to recognize the difference between converting and energizing. In this setting, converting is the act of trying to persuade new people to side with your cause or invest in some way; energizing is the act of deepening an existing relationship or motivating someone to act in some way. The way you engage online should vary depending on whether your audience primarily consists of dedicated volunteers or those who have no prior knowledge of your organization. Fortunately, online channels tend to self-segment – a Facebook page is likely to be dominated with those who need energizing. A blog will often reach a far more diverse audience who aren’t already invested.
3. Use social and online media to humanize your organization. It’s tempting to take press releases or other news items and blast them out on all available channels. But that’s not the best use of social media – it disconnects you from your audience rather than creating a closer connection. This is your opportunity to put a more human face to your organization: telling the inside story, being open and transparent about how you think through issues and challenges, and providing a perspective that others can relate to. Ensure that you don’t edit out the personality. Tell people about the things you’ve done right, and the things you can learn from.
4. Be timely. Social media is about a flow of discourse and a conversation, rather than about blasting your message out to an audience. Use channels like Twitter and blogs to provide an up-to-the-minute view of the work you’re doing, offering fresh, first-hand updates on the situation that respond to current trends or news. You can only set the news agenda when you’re part of this flow.
5. Don’t moderate views that you dislike. To some people this is obvious, to others it’s counter-intuitive. If you are changing perceptions, you’re necessarily going to be bumping into those who don’t share your views. On a blog, it’s tempting to moderate or delete comments that provide an opposing view: it feels like a guest has come into your home and is insulting your choice of décor. Yet for the most part, these are the comments to relish: they demonstrate that you are engaged in an authentic conversation that is generating a reaction. There’s a lot more to say on this topic that I’ll perhaps address in a future post.
6. Build a public record. Particularly with blogs, podcasts and similar channels, consistency is key. Unless you establish a regular cadence of content, you’ll never establish a regular cadence of visitors. That doesn’t mean you have to post at a certain time each day: you don’t have to be rigid about it, but don’t go dark for weeks on end either. Remember that everything you post has a lifetime that extends for years beyond the original week of posting. Looking at the traffic to my blog, maybe as much as two-thirds of it goes to content I wrote in the preceding months rather than what is on the current home page.
7. Be a recommendation engine. In social media, the currency traded isn’t the dollar: it’s influence, reputation and audience. Use your own influence and reputation to give other interesting organizations or individuals their own spotlight. Follow and link to those around you who are doing interesting things. Unlike real money, trading online currency is that it isn’t a zero-sum game – in fact, the more you give, the more you earn. Even your competitors can be your allies in this regard. But whatever you do, be authentic – don’t fall into the trap of trading links for cynical gain. Make your recommendations count.
8. Strike up a conversation. The single most valuable outcome of social media is to strike up a conversation with your supporters or customers, giving you a much more accurate ability to channel their needs and wants. Don’t just pontificate: ask questions. The goal isn’t to preach, it’s to collaborate. You need to listen more than you talk. Give air for others to contribute – don’t leap in immediately with a reply to any comment that’s made because that stifles a broader discussion. Show you’re listening by responding, but don’t necessarily feel the need to offer a blow-by-blow response to every point that’s made.
9. Understand the volume level. Once in a while you have an earth-shattering announcement that blows out the barn doors. But not everything “goes to 11”. It’s important to understand the volume level you want to apply to what you share, otherwise it’ll be hard for others to spot when you’re telling them something big. My team often talks about new things we’re doing in terms of the impact it’s going to make – to use another analogy, how much it “moves the needle”. You have to have dynamic range in your communications – if everything is shouted from the rooftops, people will stop listening.
10. To build traffic, go where your audience is. Don’t spam or steal someone else’s platform to push your cause. But spend time growing your profile and influence through others’ sites. Get involved and comment – become known for insightful responses that add value to the debates folks are having in other forums. When posting comments on another blog, use your real email and web address, but don’t be nakedly self-promoting.

What do you think? What would you add? What are your most effective strategies? Have you seen good counter-examples where the “accepted wisdom” is in fact the wrong way to engage?

Language designers need to observe and integrate major trends into their work. Over the last few years, we’ve seen several major trends: (i) declarative styles – where you say more about the ‘what’ and less about the ‘how’, e.g. DSLs, functional programming; (ii) the resurgence of dynamic languages like Ruby and JavaScript, and how that affects static typed languages; (iii) concurrency.

In the last major editions of the language, there has been significant investment in declarative styles and dynamic programming. But there isn’t heavy language support for concurrency today, even though there is good support in the framework through the likes of the Task Parallel Library.

One reason for the rise in concurrency is the rise in connected applications: it’s almost impossible today to build an application that doesn’t talk to a service, or indeed to build a service that doesn’t talk to another service. This increases latency – for example, it is just not acceptable for a UI to freeze while it waits for a service to return. As a result, we all practice the art of asynchronous programming. It is starting to become the norm, and we’re even starting to see the rise of async-only APIs in languages like JavaScript and Silverlight.

As a result, we’re looking at making concurrency the theme of the next release of our C# and Visual Basic languages.

The Challenges of Asynchronous Programming

In a synchronous call, the act of invoking a method and waiting for the result are fused: you can’t separate the two. With asynchronous programming, that changes. You can call the method and it will return immediately; later, it will deliver the result, so the two operations are separable.

There are a few problems with today’s model: (i) that the function can’t return the result, since the code is asynchronously executing, so it has to use a callback instead; (ii) it can be complex to update the UI without marshaling data back from a background thread; (iii) in a server setting, you don’t really want unconstrained thread creation because of the increased competition to the thread pool.

Anders demonstrated a simple example that shows how complex the asynchronous model quickly becomes. The code fragment below downloads and display movies based on a query of the NetFlix OData feed:

Movie[] QueryMovies(int year, int first, int count) {

  var client = new WebClient();

  var url = String.Format(query, year, first, count);

  var data = client.DownloadString(new Uri(url));

  var movies = 

    from entry in XDocument.Parse(data).Descendants(xa + "entry")

    let properties = entry.Element(xm + "properties")

    select new Movie {

      Title = (string)entry.Element(xa + "title"),

      Url = (string)properties.Element(xd + "Url"),

      BoxArtUrl = (string)properties.Element(xd + "BoxArt").Element(xd + "LargeUrl")

    };

    return movies.ToArray();

}

But this code is synchronous – the UI will hang while waiting for the call to return. Let’s follow through the steps needed to fix this:

• We can replace the DownloadString() method with DownloadStringAsync();
• Then we need to separate out the remaining code in the method to a handler for the DownloadStringCompleted event;
• But how do we then return the result to the calling method? The QueryMovies method will already completed by this point. We can’t – instead, we need to make this method async as well, adding an Action<> delegate as a parameter.
• Now we have to go back to the method that called QueryMovies and retrieve the result asynchronously . And this is where it really starts to get unpleasant, because QueryMovies is being called in a while loop, as follows:

  void LoadMovies(int year) {

    resultsPanel.Children.Clear();

    statusText.Text = "";

    var pageSize = 10;

    var imageCount = 0;

    while (true) {

      var movies = QueryMovies(year, imageCount, pageSize);

      if (movies.Length == 0) break;

      DisplayMovies(movies);

      imageCount += movies.Length;

    }

    statusText.Text = string.Format("{0} Titles", imageCount);

  }

• How do we pass a delegate to a while loop? It’s delegates all the way down. Instead we have to replace the while loop and reorder the code, as shown below: 

    ...

    action = movies => {

      if (movies.Length > 0) {

        DisplayMovies(movies);

        imageCount += movies.Length;

        QueryMovies(year, imageCount, pageSize, action);

    }

    else { 

      statusText.Text = string.Format("{0} Titles", imageCount);

    }

    ...

As shown in the code above, you can do it – but it’s unwieldy, and the flow of the code gets lost. And this is before we’ve dealt with error handling! Clearly we can do better.

New Async Features

The Visual Studio Async CTP, announced at PDC, introduces some new extensions to VB and C# to support a simpler, more declarative approach to asynchronous development.

The Task Parallel Library introduced a Task<T> type, which is used to represent an ongoing operation: a value that is currently being computed and will be delivered at some time in the future. We can use this as the return type along with a new async keyword to let the compiler know how it will be used, as follows:

async Task<Movie[]> QueryMoviesAsync(int year, int first, int count) {  

We now can add some asynchronous work to the class. The CTP introduces a number of Task<T>-centric extension methods that will eventually be added into the core framework, which enable us to compose and call other asynchronous methods seamlessly. For example, the call to DownloadString() in our original method can be replaced by a call to DownloadStringTaskAsync(), which returns Task<string> instead of just string. (This is something you can offer for your APIs too, of course.)

And we can now use the await operator, as follows:

  var data = await client.DownloadStringTaskAsync(new Uri(url));

The compiler rewrites your code (as it does for iterators), to use a continuation and then return, executing the rest of the code when the result becomes available.

Now the LoadMovies() method is really simple. Starting with the original code above, we can again mark the header with the async keyword and then we can call the new async version of QueryMovies using the same await operator:

  var movies = await QueryMoviesAsync(year, imageCount, pageSize);

That’s all you have to do! As you can see, the new syntax preserves the logical syntax of the code. Exception handling requires no additional work: we don’t need to worry about callbacks, for instance.

It’s relatively easy to cancel an asynchronously executing task: you use the .NET 4 cancellation types, specifically CancellationToken and CancellationTokenSource, to indicate a request to cancel the task. The token can be passed into the DownloadStringTaskAsync() method. Everything here is just as before.

Background and Foreground Threads

It’s important to note that the example shown above does not use a background thread – the async calls are happening on the UI thread. They aren’t computationally expensive; they are just blocking on a network call.

What if there is something that is computationally expensive that you do want to run on a background thread? You can simply use a lambda within an await context, for example:

async void ComputeStuffAsync() {

  double result = 0;

  await TaskEx.Run(() => {

    for (int i=1; i < 500000000; i++) {

      result += Math.Sqrt(i);

    }

  });

  MessageBox.Show("The result is " + result, "Background Task",

    MessageBoxButton.OK, MessageBoxImage.Information);

}

In summary, what the new asynchronous support offers is an abstraction layer that unifies computational, network and I/O asynchrony. For more information on the features, you can read a whitepaper on the MSDN site. There are also a number of good samples in the CTP, including the example demonstrated above.

It’s important to start by understanding the difference between retained mode and an immediate mode graphics models:

• In a retained mode API, the structure of a graphical scene or object is stored in memory as a graph. The runtime itself is responsible for drawing the scene or elements of the scene as appropriate.
• In an immediate mode API, it is the application that is responsible for drawing the scene and you can’t manipulate an object in the scene once it has been drawn. Each has their benefits, depending on the style of application being created, as we’ll see.

More information on retained and immediate mode models can be found on MSDN.

SVG is a retained-mode graphics model. To build a scene graph in SVG, you write declarative markup to create an in-memory tree structure that lives in the HTML DOM. You can manipulate the scene graph through code or through CSS. SVG markup can be generated from a variety of tools, including Adobe Illustrator and Microsoft Visio.

Canvas is the immediate-mode graphics model. Because it doesn’t store the graph in memory, it takes less memory overhead to use, and can be faster for intensive use. Unlike SVG, it is programmatic in nature – there is only one parent <canvas> element, and code is used to populate it. While you draw primitive objects on a canvas, the only thing that is stored is the generated bitmap surface. In general, canvas is a lower-level API than SVG because of these constraints.

A quick tabular comparison of the two technologies:

Given these characteristics, what is the best technology to use for a specific scenario? SVG is perfect for high-fidelity documents and graphics for viewing and printing, and for interactive charts and maps. On the other hand, canvas is perfect for mathematically-intensive operations and complex scenes. However, there are a lot of cross-over scenarios where there’s no clear winner at this point in time, and as browsers evolve and improve, it seems that the performance characteristics of both technologies are starting to converge. Both technologies are clearly valuable!

[Session CD53 | presented by Patrick Dengler]

At its heart, MVVM imposes three kinds of classes that separate out ideas of presentation (Views), logic (ViewModels) and data (Models). Some of the advantages of structuring a project this way: (i) it facilitates code separation, which helps testability and helps you focus your classes on a specific role; (ii) it supports well the data binding architecture of Silverlight and WPF; (iii) it enables designers and developers to collaborate on a project with minimal overhead. (iv) it is a consistent, maintainable, well-understood pattern; (v) it scales well from small to large applications.

Models, Views, and ViewModels

Let’s take a look at each of the components of MVVM in a little more detail:

• The Model is the domain object or entity: it’s a class of properties that has the responsibility of storing your data (for example, a Person object that stores a name and address).
• The View represents a screen, a page or even a control on the page. It provides a user-friendly presentation of the data, including themes, styles, declarative bindings, events, display of validation errors.
• The ViewModel glues the View to the Model. It can interact through data bindings to talk to the view – presenting data, retrieving or saving data, talking to services, or handling any actions that might happen on the UI.

As shown in the diagram above, the ViewModel is the DataContext for the View, and that is how it gets data and commands. In general you should try and move as much code as possible out of the View and into the ViewModel – this makes it easier to unit test the code through the use of mock objects. The Model is fairly straightforward: the main step you need to take is to implement the INotifyPropertyChanged interface to provide a notification that the data has changed. Lastly, there are various techniques for binding the View to the ViewModel: in this session you’ll see them being bound with a ViewModelLocator.

Commands and Behaviors

What happens after you want to display data? For example, what if you want to perform some action based on a UI interaction? This is where commands and behaviors come in.

A command is something you can fire based on a user action that starts an event in the ViewModel. It uses a binding syntax to do that. Any control that derives from ButtonBase will let you bind a command directly to it. In the ViewModel you can create your own instance of ICommand (a good recipe for this is RelayCommand from the MVVM Light toolkit) to handle the event.

For other actions where a command isn’t possible (for example, a ListBox item selection), you can use a behavior. Some good pre-built options include EventToCommand (again from MVVM Light) or InvokeCommandAction (from Blend 4’s Interactivity DLL).

Services and Separation

As we’ve seen the primary role of the ViewModel is to perform tasks: GetBook, SaveToStorage, NavigateTo etc. However, as this becomes more complex, the ViewModel starts to include code to call web services, access third-party libraries, etc. It starts to make sense to create a separate service class that separates out this helper code and makes it available across multiple ViewModels.

So services provide related tasks to the caller, and are passed through the constructor using dependency injection (passing the class into the constructor as an interface). This abstraction makes the service very testable and easy to write, and keeps a clear delineation between the task and its physical execution on the disk or network. 

Design-time Data

This is a topic that is sometimes neglected. A lot of the code in your application won’t run at design-time, because the designer can’t be waiting for a web service to return before it shows anything on screen. Design-time data ensures that you can see a fully-populated view of the UI when you’re developing or designing the application. Without some data, it’s almost impossible to style an application, or for that matter, to ensure that the bindings are right.

One way to provide design-time data is to use sample data (Expression Blend makes this relatively easy); another approach is to use design-time services. A proposed approach to this is to use a ServiceProvider, which is one line of code that automatically switches between design-time and run-time service code as appropriate.

Child Windows and Messages

The big question to answer with a child window: should you create a separate ViewModel, or use the parent’s ViewModel? Like most architectural questions, the answer is “it depends”. In some cases, the child window is deeply related to the parent child and is essentially an extension of the parent; in other cases, it’s really an unrelated screen. Depending on how you’re using the child window, either approach may be the appropriate.

One note: a child window doesn’t inherit the DataContext from its parent, so you either need to pass the ViewModel through the constructor or have the child window find the ViewModel it needs.

How should the child window be displayed? You can do this in many ways – often a delegated service is an appropriate choice. As a suitable pattern, we can use messaging to handle this.

Messages are events that provide a loosely-coupled model between the ViewModel and the child window. The process is usually triggered by a user action, which initiates a command to the ViewModel. If there is some business logic that needs to be run to determine whether to display the child window or not, that should be in the ViewModel. Then a message is used to send the request to display the window – either to a service or directly to the view. Some popular choices for the message pattern include the EventAggregator from PRISM and the Messenger class from MVVM Light.

WCF RIA Services and MVVM

RIA Services is very helpful in these kinds of applications: it takes care of managing change tracking for entities, provides methods for saving and reading data, generates entities and models, handles data validation.

With RIA Services, you create your Domain Services as you normally do; you can use the Entities as your models (they already implement INotifyPropertyChanged), and you get a DomainContext object that acts as a gateway to your services and provides change tracking.

For more on Silverlight, check out Silverlight TV and the upcoming Silverlight Firestarter event on December 2nd. Laurent Bugnion’s MVVM Light Toolkit is available here.

[Session CD50 | presented by John Papa]

Scripting Engine Design Challenges

Prior to IE9, the JavaScript engine was built from an original design optimized for many different uses beyond IE (for example, Windows Scripting Host). As a result, it was designed as a component that could be dropped into different applications, with COM used to marshal data between the engine and its host application. COM-based marshaling added an overhead of 10-20% to the overall page load time, due to all the required boxing and unboxing.

Today’s engine needs to be optimized for a different set of scenarios: the browser is now by far the most prevalent usage scenario for our JavaScript engine, and these days there’s no question about which scripting language is dominant, so the browser has a far reduced need for extensibility.

On top of the architectural changes, we enable compilation to native machine instructions to provide a performance boost at execution time, particularly with large codebases. (See also the session on IE9 performance by Jason Weber for further details on this.)

Chakra

Chakra offers a hybrid approach, with both interpreter and designer built into the design. By having the interpreter running on the UI thread, we can stay responsive; but we still get the benefits of compilation through a background thread. It’s not a simple task, however – challenges we had to solve included keeping a tight memory footprint and optimizing compilation for real-world patterns.

The diagram below shows an architectural view of Chakra:

We don’t compile all code, instead, we keep a compilation queue; we speculatively compile some quantity of code, but use heuristics to prioritize the queue based on most frequently called functions, the size of the function etc.

We’ve spent time validating the design of Chakra against real-world websites. For page load times, we’re seeing an average of 14-15% improvement performance improvement – not just for the engine but across the entire stack.

IE9 introduces a new type system for JavaScript. Dynamic languages in particular need an efficient type system – types are created at runtime and multiple objects often have the same set of property. By providing a type evolution model that shares types, we can be much more efficient in these scenarios.

One important property-based technique introduced in IE9 is inline caching. Since property access is the most widely used operation and the same key of a key-value pair is often accessed multiple times on a call site, we simply cache the value for each call site.

The old JavaScript engine used to only work with 8-byte representations of numbers, even if they required less precision. Chakra introduces tagged integer support – with 31-bit numbers (a flag is used for the 32nd bit as an indicator); we go to a full 8-byte representation automatically if the number grows to require more then 31 bits of precision.

In a similar vein to tagged integer support, Chakra avoids conversion to UTF-16 where possible, retaining strings in UTF-8. This results in a gain of about 300-400K in working set and 3-4% load size wins for complex apps.

One piece of research which was particularly helpful in planning was done by Microsoft Research. The JSMeter project was conducted to measure real-world usage of JavaScript on top sites. One specific insight related to the percentage of code that sites load that is actually executed. For most large sites (including Amazon, Bing, CNN, eBay, Facebook etc.) only 40% of the code fetched is executed. Learning from this, Chakra uses a deferred parser, which reduces working set and increasing load times. (Note that you can also use the HTML <script defer> attribute to manually hint to the scripting engine that it needn’t execute a certain block of code during page loading.)

New ECMAScript 5 Features

The relatively recent release of ECMAScript 5 introduces a number of new keywords and language features. For backward-compatibility reasons, these features are only enabled in IE9 when IE9 Standards Mode is enabled (by default for external sites unless an older compatibility mode has been selected).

There is a very detailed blog post on the ES5 features added to Internet Explorer 9 on the IE engineering blog (also see this update).

You can see a fun test of browser support for various DOM capabilities on the IE Test Drive site.

[Session CD08 | presented by Gaurav Seth]

Different browsers may organize their internal implementation differently, but all these elements are important in their impact of the overall performance of a site.

An interesting lesson we can draw from the data we’ve measured in our research: site performance is not strongly correlated with the number of elements, CSS rules and amount of JavaScript code. Many people assume that JavaScript is the most significant indicator for browser performance, but the sample shows that it accounts for less than one-quarter of the overall client page load time. 

So the key lesson is that browser performance requires all the subsystems involved in page display to be optimized, rather than just the script subsystem. In IE9, we have rewritten a number of the eleven subsystems for maximum performance, and we’re going to cover a couple of these in greater detail.

JavaScript

Starting with JavaScript, IE9 introduces the new Chakra engine.

JavaScript engines can be placed on a continuum from a pure interpreter to a pure compiler. But picking one or the other end of the spectrum introduces compromises. IE9 is the first browser to do both: to build a full interpreter and a full compiler that are truly integrated. Because the compilation happens in parallel with the rendering, with every compiled function becoming available as soon as it is ready, the compiled code is available quickly to the page, while the interpreter can be used in the meantime.

This architecture makes sense because of the growth of multi-core client machines running Windows. Our data shows that the mean average number of cores on a Windows Vista or Windows 7 machine (i.e. machines that support the system requirements for IE9) is 2.46. In IE8, the ecosystem was not yet ready for this change, and so the interpreter there only takes advantage of a single core.

Another aspect of the change is the way the JavaScript engine integration has changed from IE8. In the past, COM was used as the bridge between the various language engines and the browser. This offered a lot of extensibility, but at an overhead for the primary language of the web. In IE9, we’ve built JavaScript directly into the browser as a first-class citizen, enabling the compiler and the browser engines to communicate directly via shared memory. We still support other language engines via the traditional COM mechanism.

One last interesting piece of data – we crawled the API usage of the top 7,200 websites worldwide, and discovered that the Pareto principle applies pretty accurately. Over 80% of the APIs in JavaScript are unused on 90% of the top sites. And surprisingly, indexOf() is the most commonly called function (not getElementById() as most people assume). This kind of data helped us optimize Chakra for real-world usage rather than synthetic benchmarks.

Hardware-accelerated Graphics

Every Windows computer has a GPU these days, and on Windows Vista or above, over 80% of machines have a graphics score of greater than 3.0. The GPU has become a highly-specialized computational engine optimized for graphics. Ten years ago, the CPU and GPU were roughly comparable in terms of the number of floating point operations per second each processor could deliver; today, the fastest GPUs in the world have a 10x advantage over the fastest CPUs in the world, delivering over a teraflop of computing power.

IE9 fully unlocks the GPU, using DirectX technologies like Direct2D and DirectWrite to accelerate everything in the browser: images, text, video, SVG, canvas, and CSS3. This has a dramatic impact on the performance of Internet Explorer 9 for visually-intensive websites, both compared to IE8 and indeed competitive browsers, as the following CPU usage graph shows while profiling one animation step in the Flying Images demo:

Other browsers are starting to add hardware acceleration – but no other browser available today adds hardware acceleration for more than a couple of technologies – for example, text, video, SVG remain CPU-bound on most other browsers.

[Session CD09 | presented by Jason Weber]

Physical Memory and Working Set

The working set is the physical memory that Windows gives to your process, given to you when you demand it by touching the virtual address space. A process starts with an empty working set – as it references pages that aren’t in the working set, it incurs a page fault. Many such page faults are resolved simply from memory (for example, if you load an image that is already in the file cache).

Each process has a working set default minimum and maximum. Windows doesn’t pay any attention to the maximum working set; Windows uses the minimum to commit that amount of memory, as well as to lock memory.

At some point, the memory manager decides the process is large enough; it then gives up pages to make room for new pages. If your process is ballooning, the memory manager will tend to favor it because it is obviously memory-hungry; but at some stage, it will start to pull pages out of the working set that are least recently used before it will allocate new memory to that process.

Unlike other OS, it is a local page replacement policy, meaning that it will pull the pages from the requesting process.

The working set consists of shareable and private pages; there are performance counters that measure this. Shareable working set is effectively counted as “private” if it is not shared. Note that the working set does not include trimmed memory that is still cached.

Windows Task Manager only offers the private working set figure; Process Explorer gives you a more detailed view. Remember – it’s only when you touch the memory that is committed that it becomes part of the private working set. Comparing testlimit with –m, –r and –d switches demonstrates the differences here.

Physical Memory Page Lists

The system keeps unassigned physical pages on one of several page lists in the Page Frame Number (PFN) database, each maintained as FIFO list:

• free (available for allocation but has dirty data in it);
• modified (previously belonging to a process but needing to be written to a backing store before it can be reused;
• standby (still associated with a process but not included in the working set);
• zero (zeroed out memory safe for allocation),
• ROM (read-only memory)
• bad (pages that failed internal consistency checks).

Note that meminfo gives you a way to investigate these page lists: Alex Ionescu provides further helpful commentary on the tool on his blog.)

When Windows starts, all memory is in the free page list.  As a process demands memory, it is faulted in from the zero page list (however, the free page list can be used if the memory is to be used for a mapped file, since the data will be overwritten before the process sees it). If a page is pulled from a process, it may be moved to the modified or the standby page, depending on whether it contains private data that needs to be flushed or not. When a process exists, its pages are moved to the free page list.

There are two threads that are specifically responsible for moving threads from one list to another. Firstly, the zero page thread runs at the lowest priority and is responsible for zeroing out free pages before moving them to the zeroed page list. Secondly the modified page writer is responsible for moving pages from the modified page list to the standby page list, first writing out any data.

What happens if the zero and free pages are exhausted? The memory manager starts using the standby page list; if that is exhausted, then the modified page list can be used (once the modified page writer has flushed the content and moved it to the standby page list). If all these pages are exhausted, the last resource is to remove memory from the working set.

With this information, we can more helpfully interpret the data provided by Task Manager.

• The Available field (right) shows all the pages in the zero, free and standby lists.
• The Cached field shows all the pages in the standby and modified page lists as well as the system  (kernel) working set.
• The Free field shows just those pages in the free and zero page lists.

Rammap is another useful tool, showing the most detailed breakdown of what’s going on in RAM at the time it takes the snapshot. It breaks down all the memory in the system by type and page list. For processes, it shows the private working set for each process as well as memory for that process on the standby or modify page list as well as kernel memory in the page table.

As you can see, having a low “free memory” value in Windows is normal – and a good thing. In fact, a technology like SuperFetch has the goal of reducing free memory (moving pages from the free to the standby list as it caches files into memory).

SuperFetch is used to proactively repopulate RAM with what it believes is the most useful data: it takes into account the frequency of page usage, and the usage of the page in the context of other pages in memory. Interestingly, the choices it makes are also influenced by a time-based heuristic – it understands that users launch different applications at the weekend than during the weekday, and at the evening than the daytime. SuperFetch is disabled in Windows 7 if the operating system is booted from an SSD drive, because the primary benefit is to reduce random read seeks on a platter-based hard drive.

It’s worth noting that there are actually eight standby page lists in practice on Windows Vista and above; this is used to ensure that the least important standby pages are scavenged first. (Rammap can show you how much memory has been repurposed from each of the standby priority lists.)

A common question: do you have enough RAM in your system? There’s actually no sure-fire way to tell if you have enough memory. If available memory is low for a considerable length of time, then you probably could use more. You can check Process Monitor to see if there are an excessive number of reads from the paging file (there’s no performance counter for paging file reads).

Mark closed with some examples of how certain memory usage can be hard to or inspect or detect: a shared memory leak, large quantities of reserved but uncommitted memory, locked memory, driver locked pages and AWE pages.

[Session CD02 | presented by Mark Russinovich]

Windows has both physical and virtual memory. Memory is managed in pages, with processes demanding it as necessary. Memory pages are 4KB in size (both for physical and virtual memory); but you can also allocate memory in large (2-4MB, depending on architecture) pages for efficiency. In general, there are very few things in common between physical and virtual memory, as we’ll see.

On 32-bit (x86) architectures, the total addressable memory is 4GB (2³² bytes), divided equally into user space and system space. Pages in system space can only be accessed from kernel mode; user-mode processes (application code) can only access data that is appropriately marked in user mode. There is one single 2GB system space that is mapped into the address space for all processes; each process also has its own 2GB user space. (You can adjust the split to 3GB user / 1GB system on PAE-enabled systems, but the 4GB overall address space limit remains.)

With a 64-bit architecture, the total address space is theoretically 2⁶⁴ = 16EB, but for a variety of software and hardware architectural reasons, 64-bit Windows only supports 2⁴⁴ = 16TB today, split equally between user and system space. Mark: “I think I’m pretty safe in saying that we’ll never need more than 16TB, but people smarter than me have been proven wrong with statements like that, so I’m not sure if I should make that claim or not!”

Virtual Memory

Within a process, virtual memory is broken into three categories: (i) private virtual memory – that which is not shared – e.g. the process heap; (ii) shareable – memory mapped files or space that you’ve explicitly chosen to share; (iii) free – memory with an as yet undefined use. Private and shareable memory can also be flagged in two ways: reserved (a thread has plans to use this range but it isn’t available yet), and committed (available to use). Why should you reserve memory? It allows an application to lazily commit contiguous memory. For example, a stack: the system only needs to commit a small amount in advance, and can grow as appropriate by committing previously-reserved memory.

Task Manager only lets you see the private bytes (“commit size”); indeed, most virtual memory problems are due to a process leaking private committed memory, since it backs the various heaps in the system. But this doesn’t offer a full view of the address space – it doesn’t account for shareable memory that isn’t shared (e.g. a DLL only loaded by this process). Fragmentation can also be an issue, causing the address space to be exhausted prematurely. Process Explorer lets you split out the overall virtual memory used by a process from the private bytes; another useful tool is VMMap (with a new v3.0 released for PDC10), which provides a really deep level of inspection into the virtual memory used by a given process.

In the example above, the committed memory is about 54MB, but only a tiny amount is private. The middle section shows how the memory is allocated –  images (DLLs and executables), mapped files, shared sections, heaps (unmanaged and managed), the stack region, private data (memory that is private and doesn’t fall into one of the other categories, e.g. if you call VirtualAlloc()), and page tables. If you click on one of these rows, you’ll filter the details section at the bottom of the window.

Fragmentation can be an issue, as mentioned earlier. Mark demonstrated creating a large number of threads with testlimit –t. The number of threads he was able to create on a 32-bit machine was limited to ~2900 even though in theory he should have been able to create more, because the address space was so fragmented that there were no more contiguous spaces of 1MB or more (1MB being the default size).

Mapped Files

Mark then demonstrated how mapped files are used heavily by Explorer. Files are mapped regularly so that it can get access to the resources and metadata from within them. You can trace file mappings with Process Monitor – so if you don’t understand why a file is mapped, you can see how the DLL got loaded by capturing a snapshot filtered to “Load Image” operations and examining the stack at the point the image was loaded.

You can also use VMMap to compare the difference between two snapshots of a process. In the given example of loading a file into Notepad, the committed memory grew from the 54MB above to over 100MB – with most of it coming from image loading.

New in VMMap 3.0 is tracing, which enables you to launch a process with profiling and track virtual and heap activity over a period of time.

System Commit Limit and Paging Files

Certain kinds of process committed memory are charged against the system commit limit. System committed memory is that which is backed either by the paging file or physical memory. Not all memory in the address space is system committed memory – for example, the notepad.exe image or its DLLs are backed by disk, so if the system tossed out of memory and Notepad wanted to access it again, it could simply retrieve it from notepad.exe on disk.

When Windows needs to reallocate private memory, it has to store it in the paging file (otherwise it would be missing when it needed to retrieve it). When that limit is reached, you’ve run out of virtual memory. You can increase the system commit limit by adding RAM or increasing the paging file size: if paging files are configured to expand, that means that the system commit limit may not actually be the maximum limit.

So how is the paging file size determined? By default, it is automatically managed by Windows based on the RAM available: on systems with >1GB RAM, the minimum is equal to the size of the RAM and the maximum is 3x RAM or 4GB (whichever is larger). You can manually adjust this, however.

What’s ironic about this algorithm is that in the dialog, the recommended value is often a completely different number (on my 8GB machine, it’s 1.4x RAM), which as Mark notes fails to inspire confidence in the algorithm.

You can view system commit charge and limit from Task Manager or Process Explorer; you can test exhausting the system commit limit by running testlimit –m. (Be careful – this will stress your machine to its limit!)

So how should you size your paging file? Many people will give you advice based in multiples of the RAM, but that isn’t good advice.  You should look at the system commit peak for the most extreme workload and if you want to apply a multiplication factor (1.5x, 2x), apply it to that value instead. Note that it’s important to ensure that the paging file is big enough to hold a kernel crash dump. Although you can turn off the paging file altogether, it is useful – the system can page out unused, modified private pages, providing more RAM for real workloads.

[Session CD01 | presented by Mark Russinovich]