Inside the Windows Phone Emulator

Learn from the dev lead and PM of Windows Phone 7 Emulator on how it works and delivers the awesome performance.

Some key points

1. The emulator is essentially a x86 based Virtual Machine running full image of Windows Phone 7 OS
2. It emulates various peripherals (e.g. audio, networking), the list hopefully will grow in the future
3. Supports multi-touch if your host PC has a touch screen
4. It uses the GPU on the host PC to accelerate the graphics
5. Shameless plug: One of the reason it’s possible to emulate x86 and still have managed apps running as-is, is because the runtime (.NET Compact Framework) supports both x86 and ARM seamlessly (provides JITer for both architectures and runs the same managed code on both seamlessly)

Working in the United States

I am sure everyone has read about the “you cannot possibly pronounce or spell” volcano in Iceland throwing up in the air and screwing up the entire flight system of this planet. While most people were reading about it from the comfort of their home I was doing the same while waiting in airports with a 5 year old tagged along. Anyways, 48 hours and a switch in the direction of flights got me to some countries I didn’t really plan to visit and over the Pacific to land in Seattle.

Going forward I will be working out of the Microsoft Redmond offices, doing pretty much the same stuff I was doing before (working on the .NET Compact Framework runtime).

Right now I am settling down with my family and my daughter is excited to see snow for the first time (she got lucky as there was a small snowfall on Saturday in Snoqualmie pass). The changes we need to adjust to is humongous, we left Hyderabad when it was 43° Celsius and now it’s 6° Celsius in Redmond. Oh sorry I should’ve said it was 110°F and now it’s  43°F in Redmond.

Wish me luck and hopefully finally I will be able to attend some nerddinners.

We Believe in Sharing

In Building NETCF for Windows Phone 7 series we put in couple of features to enhance startup performance and ensure that the working set remains small. One of these features added is code/data sharing.

Native applications have inherent sharing where multiple processes can share the same executable code. However, in case of managed code running on NETCF 3.5 even when multiple applications use the same assembly, the managed code in them are JITed in context of each process separately. This results in suboptimal resource utilization because of the following

1. Repeated JITing of the same code
2. Memory overhead of having identical copies of the same JITed code for every process running them. The execution engine also maintains records of the various types loaded and even though two (or more) processes may be loading the same types from the same assemblies; per process copies are maintained for them.

Together the overhead can be significant.

In the latest version of the runtime shipping with Windows Phone 7 (.NET Compact Framework 3.7) we added a feature to share both the JITed code and these type information across multiple managed processes.

The runtime essentially uses a client server architecture. We added a new kernel mode server
which is responsible of maintaining a system wide shared heap. The server on receiving requests
from the various client processes (each managed app is a client) JITs code and type information
into this shared heap. The shared heap is accessed Read-only from all the client apps and
Read/write from the server.

When a process requests for the same type to be loaded or code to be JITed it just re-uses the already loaded type info or JITed code from the shared heap.
What is shared

1. Various Execution engine data-structures like loader type-information
2. JITed code from a predefined list of platform assemblies (user code is not shared).

Do note that user code is not shared and neither is all platform code. Sharing arbitrarily would actually increase cost if they ultimately didn’t get reused in a lot of applications. The list of assemblies/data shared was carefully chosen and tuned to ensure only those are shared that provided the maximum performance benefit.

Sharing provides the following advantages

1. Warm startup time is significantly reduced. When a new application is coming up a large
   percentage of the initial code and type-info is already found on the shared heap and hence
   there is significant perf boost. The exact number depends on the applications but it’s common
   to get around 30% gains
2. Significant reduction in net working set as a lot of commonly used platform assembly JITed code is re-used
3. Obviously there are other goodness like less JITing means less processing on the device

Like user code the system is also capable of pitching the shared code when there is a low memory situation on the device.

Comparing Windows Phone with .NET Compact Framework 3.5

In the comments of my previous post Windows Phone 7 Series Programming Model and elsewhere (e.g. twitter, WP7 forum) there seems to be a lot of confusion around how NETCF 3.5 compares against the new WP7 programming model powered by NETCF 3.7. People are asking why some API got removed from 3.5, or is 3.7 a subset of NETCF 3.5 as they are not seeing some familiar 3.5 APIs.

First I’d urge you to go visit the Windows Phone 7 Series Programming Model to see what it offers.

Essentially NETCF 3.5 can be broken down to

1. NETCF 3.5 runtime (the Execution Engine)
2. NETCF 3.5 BCL
3. NETCF 3.5 UI programming model (WinForm based)

Now each of this has been updated (in order) as follows

1. NETCF 3.7 runtime (hugely updated Execution Engine)
2. NETCF 3.7 BCL (essentially offering the Silverlight 3 BCL Apis with a small delta)
3. The UI model has been replaced and offers two options
   1. Silverlight 3 UI + Windows Phone device specific features (e.g. accelerometer , location service)
   2. XNA features with Windows Phone device specific features (e.g. accelerometer , location service)

So the runtime is hugely updated (and hopefully you’d feel the improvements, especially in performance).

For #2 and #3 the level of difference is same in magnitude as you compare WinForm with Silverlight on desktop. They are simply two different programming models.

In case you hit a 3.5 API  that’s missing then it’s either because it’s (a) WinForm based API that got totally replaced, or (b) a BCL API that the Silverlight profile doesn’t support. The workaround is to search for how to do the same thing in Silverlight (e.g. use XDocument instead of XmlDocument). In some cases you’d get into situations where there is no direct alternative. E.g. there is no P/Invoke and if your code say P/Invoked to get data from a bar-code scanner you cannot do so now.

Also keep in mind that the bits available right now is just early preview bits and subject to a lot of change. The whole purpose of having CTPs is to hear our customers and ensure we use the remaining time before release in fixing issues that helps our customers the most. Hopefully some of the gaps will get closed before the final release.

Silverlight on Nokia S60 platform

Today at MIX 2010 we announced Silverlight beta for Nokia S60 phones. Go download the beta from http://silverlight.net/getstarted/devices/symbian/. 

Currently the supported platform is S60 5th Edition phones and in particular the 5800 XpressMusic, N97 and N97 mini. It works in-browser and only in the Nokia default web-kit based browser.

Silverlight on S60 uses .NET Compact Framework (NETCF) underneath it. I work in the dev team for the Execution Engine of NETCF and I was involved at the very beginning with getting NETCF to work on the S60 platform.

NETCF is extremely portable (more about that in later posts) and hence we didn’t have a lot of trouble getting it onto S60. We abstract away the platform by coding against a generic platform abstraction layer (PAL), but even then we had some challenges. Getting .NET platform on a non-Windows OS is challenging because so much of our code relies on Windows like functionality (semantics) which might not be available directly on other platforms.

As I was digging through emails I found the following screenshot that I had sent out to the team when I just got NETCF to work on the S60 Emulator…

As you can see the first code to run was a console application and it was not Hello World :). We have come a long way since then as evident from the touch based casual game running on the N97 shown below

Windows Phone 7 Series Programming Model

Just sometime back I posted on the MIX 2010 announcements. One of the major aspects of the announcement was

“The application model supported on Windows Phone 7 series will be managed only and will leverage Silverlight, XNA and the .NET Framework”

That’s a mouthful and includes 3 framework names in once sentence :). This was already disclosed and has resulted in some flutter over the web and twitter. Let me try to explain how these 3 interplays in the application model with the following diagram

Managed only

First of all the application model allows users to write only managed code (to repeat native code is not allowed). That means they do not have direct access to any native APIs and cannot use platform-invoke to call into native user or system code. So all resources including phone capabilities have to be accessed using the various managed APIs provided.

Two Flavors of applications (XNA and Silverlight)

There are 2 variants or flavors of applications users can write, XNA Games and Silverlight applications. Obviously the former is for writing games and the later is for your typical phone applications (nothing stops you from writing a Silverlight animation based game though). So you cannot mix-match SL and XNA UI in the same application.

However, do note that the traditional NETCF development using WinForm based UI is not supported.

Common Services available to both

That said, beyond the UI rendering and controls there is the common services which both SL and XNA applications can use. This includes all the phone capabilities like microphone, location, accelerometer, sound, media, networking, etc... Some of these features come from SL and others from XNA but land up in the common pool usable by either types of applications.

Core Runtime is .NET Compact Framework 3.7

The core runtime for both SL and XNA applications is .NET Compact Framework (henceforth called NETCF). This is the team I work for.  .NETCF is a highly portable and compact (as in smaller size and footprint) implementation of the .NET specification. It is designed to run on resource constrained devices and on disparate HW and SW configurations.I will have a post later on the detailed architecture or .NETCF.

Over the last two years a lot of work has gone into .NETCF to scale it in terms of features, performance and stress to meet the requirements of Windows Phone and other newer platforms on which it is being targeted. We also added a lot of features which I hope you will enjoy. Some of the features is just to reach parity with the desktop CLR and others are device specific and not available on the desktop.

Over this blog in the course of the coming months I’ll try to share with you what all we did to reach here.

MIX 2010 Announcements

Today is a very big day for me and my team. The stuff we have been working on is finally went live on stage MIX 2010.

Windows Phone 7 is easily the most dramatic re-entry/reset Microsoft has undertaken in any field it’s in. We announced the phone in MWC and the reception it got was phenomenal. However, in the new connected devices world, the application platform+market story is as or more important than the device itself. Today at MIX we just disclosed details of that.

1. The application model supported on Windows Phone 7 series will be managed only and will leverage Silverlight, XNA and the .NET Compact Framework. So basically you can reuse your C#/.NET and Silverlight skills to build amazing experience on the phone. I will get into details of this in the coming posts
2. Microsoft just announced free Windows Phone Developer Tools (preview bits available for download head over to http://developer.windowsphone.com/ )
   1. This builds on the amazing development experience brought in by the Visual Studio 2010 shell.
   2. You can either get a standalone Visual Studio 2010 Express for Windows Phone Or an addin for your previously installed VS 2010
   3. Windows Phone 7 series emulator (yes you do not even need a device to develop for Windows Phone)
3. A version of Expression Blend is also demonstrated for the Windows Phone (a free version will be available for download in the coming months)
4. A new Windows Phone Marketplace is being put into place
   1. Developers can earn 70% revenue from the applications they sell of the marketplace
   2. The registration to the market place is not free but it’ll be free for the DreamSpark program for students

Our team was involved with building the IDE, the emulator and the core .NET runtime that powers the applications. So watch out and in the coming posts I’ll deep dive into these areas.

Bidar road trip from Hyderabad

Just went for a short day trip to Bidar from Hyderabad on Jan 16, 2010. This post is to document the whole plan and quick tips  Since we travelled with GPS and Google maps have excellent coverage of the area we didn’t face any issues.

The way to Bidar

The route maps on Google here. The total distance came out to be around 115kms from Miyapur. The route is pretty straight forward. Get onto NH9 which goes from Hyderabad to Pune and onward to Mumbai. Drive around 85km and then take a right onto SH4 and drive around 26 km to reach Bidar (which is in Karnataka). The right turn is well marked out and clearly points that it goes to Bidar.

We started around 7:00 a.m from Hyderabad and even though we expected around 2 hours of driving it turned out to be 3 hours as we took a pit-stop in the Haritha Restaurant (APTDC) for breakfast. The restaurant came around 60-65 kms from Hyderabad. The choice of food was limited but the Poori and Idli we had was steaming hot and sumptuous. The bathrooms were clean as well :). The stop is highly recommended.

The road was excellent all the way and traffic was sparse, I could drive easily at 100kmph. Just before reaching Bidar there is a reserve forest and when we were driving through a tiger leapt in front of our car. Ok I was kidding the forest is there and my daughter was trying to see a tiger :)

 

 

In Bidar

We took the following route plan inside Bidar

Just after entering Bidar (A) you’d see an old Fort gate on the right, get into it and you’ve reached the old city. After that you just need continue on the straight road. The un-mistakable clock tower (chaubara) would be infront out you.

 

 

Our first stop was the remains of the ancient theological college (B), Mohamad Gawan Madrasa. Built in 1472 by Gawan, a Persian exile and scholar of the Bahmani court, this was one of the greatest centers of Islamic learning of its time, attracting students from all over. We got some nice shots of the place and the beautiful green parrots hovering around added to the color.

From this we drove another km to the Bidar fort (C), which comes straight ahead. After getting through another set of fort gates we got into the fort.

Do note that the whole idea of fort gates is to make entry difficult and not allow you to see what is ahead, so drive carefully and honk (there is a sign that proclaims horn-mandatory).

Inside the fort we first went to the museum and then asked the folks their to show us around the fort. The fort is kept under lock-key to prevent people from scribbling pappu-loves-pinki on the walls and you need to explicitly ask to be shown around (and tip them at the end). We were shown around the various Mahals, especially the Rangeen Mahal took our breadth away. The museum also has some interesting pieces like locks which are bigger than my door and huge guns which could be carried only by people who anyway didn’t need them.

Just outside the museum is the canteen where we grabbed some food and coffee. The whole area around Bidar cultivates sugarcane, and if you are not explicit about it they’d put all of that in your cup of coffee. Energized with all that sucrose we ventured out to the back of the museum to see the diwan-e-aam and diwan-e-khaas.

After that we drove down to the Barid Shahi tombs (D). It has a nice little park and our daughter enjoyed the welcome break from seeing old buildings and enjoyed the slides and slings.

Our last stop was the Gurudwara Nanak Jhira Saheb (E). Finding the was easy as there is a gate on the SH4 from where you need to get into the road that leads to the Gurudwara. Do remember to carry shawls for women and handkerchief for men to cover the hair which is mandatory to enter the Gurudwara. In case you forget you can always get them at the Gurudwara but putting cloth which hundreds have used before might be a bit yucky :).

We paid Rs10 to get some very tasty halwa which was loaded with Ghee. The Gurudwara had clean pay-n-use loo which helped :) 

 

We asked the Sardarji security guard for some pointers for good food and we pointed to a fantastic restaurant. It’s called Rohit Restaurant and is on the road that leads to the Gurudwara from SH4 and is just beside the police chowki. It’s Punjabi cuisine, vegetarian and is clean and the food proved to be excellent (their naan/daal-fry can hands down beat any 5-star restaurant). Highly recommended.

On the way back we again went back to the Clock tower (choubara) area to pick up some Bidriware which is specialty of this City. These are hand made by putting in silver threads into copper, zinc allow casts. It’s pleasure to actually see them being made and buy from the artisans directly. Do not buy Bidri from the main road as they’d loot you. Ask for choubara and then when you reach that area ask around for the shops.

It was around 3:30 when we finished our Bidar tour and drove back to Hyd.

Tips:

1. Carry a map (print-out from Google) for Bidar city if you do not have GPS
2. Start early so that you can finish the fort before it gets too hot
3. Ask to be shown around inside Bidar fort and tip at the end
4. Carry cloth to cover head if you plan to visit the Gurudwara
5. The Rohit restaurant close to the Gurudwara is highly recommended.
6. Do buy some Bidriware (small pieces comes for around Rs.200). However, you need to go to choubara area to buy them.

If you visit Bidar and want to get something added/updated to this post do leave a comment.

.NETCF: The mini Y2K

I am sure most people haven’t yet forgotten the Y2K problem. This year our team faced a mini Y2K, but don’t worry we anticipated it and all is well.

If you head over to NETCF Wikipedia page you’d notice the NETCF versions look as follows

<MajorVersion>.<MinorVersion>.<Year><DayofYear>.<Rev>

A sample version number is

3.5.7283.0

This represents .NETCF version 3.5 build on the 283rd day of 2007. I guess by now you can guess the problem. We use a single digit to represent the year. By that nomenclature, the version of the build churned out today would be 3.5.0001.0 which is lower than the one generated the year before and would fail to install.

These numbers are automatically generated by scripts on the server that churns out daily builds. The numbering system was invented a long time ago in early 2000 and no one bothered to fix it. We anticipated that it’s going to fail as we move into the new decade and have updated it to now have 2 digits for the year (and yes we know it will break again in the future, but hopefully that’s too far out to care right now).

Happy new Year.

Back to Basics: Memory leaks in managed systems

Someone contacted me over my blog about his managed application where the working set goes on increasing and ultimately leads to out of memory. In the email at one point he states that he is using .NET and hence there should surely be no leaks. I have also talked with other folks in the past where they think likewise.

However, this is not really true. To get to the bottom of this first we need to understand what the the GC does. Do read up http://blogs.msdn.com/abhinaba/archive/2009/01/20/back-to-basics-why-use-garbage-collection.aspx.

In summary GC keeps track of object usage and collects/removes those that are no longer referenced/used by any other objects. It ensures that it doesn’t leave dangling pointers. You can find how it does this at http://blogs.msdn.com/abhinaba/archive/2009/01/25/back-to-basic-series-on-dynamic-memory-management.aspx

However, there is some catch to the statement above. The GC can only remove objects that are not in use. Unfortunately it’s easy to get into a situation where your code can result in objects never being completely de-referenced.

Example 1: Event Handling (discussed in more detail here).

Consider the following code

EventSink sink = new EventSink();
EventSource src = new EventSource();

src.SomeEvent += sink.EventHandler;
src.DoWork();

sink = null;
// Force collection
GC.Collect();
GC.WaitForPendingFinalizers();

In this example at the point where we are forcing a GC there is no reference to sink (explicitly via sink = null ), however, even then sink will not be collected. The reason is that sink is being used as an event handler and hence src is holding an reference to sink (so that it can callback into sink.EventHandler once the src.SomeEvent is fired) and stopping it from getting collected

Example 2: Mutating objects in collection (discussed here)

There can be even more involved cases. Around 2 years back I saw an issue where objects were being placed inside a Dictionary and later retrieved, used and discarded. Now retrieval was done using the object key. The flow was something like

1. Create Object and put it in a Dictionary
   
2. Later get object using object key
   
3. Call some functions on the object
   
4. Again get the object by key and remove it

Now the object was not immutable and in using the object in step 3 some fields of that object got modified and the same field was used for calculating the objects hash code (used in overloaded GetHashCode). This meant the Remove call in step 4 didn’t find the object and it remained inside the dictionary. Can you guess why changing a field of an object that is used in GetHashCode fails it from being retrieved from the dictionary? Check out http://blogs.msdn.com/abhinaba/archive/2007/10/18/mutable-objects-and-hashcode.aspx to know why this happens.

There are many more examples where this can happen.

So we can conclude that memory leaks is common in managed memory as well but it typically happens a bit differently where some references are not cleared as they should’ve been and the GC finds these objects referenced by others and does not collect them.

Some things I have learnt amount SW development

Working in the developer division is very exciting because I can relate so well with the customers. However, that is also an issue. You relate so well that you tend to evolve some strong opinions that can cloud your view. While working in the Visual Studio Team System team and now in the .NET Compact Framework team I have learnt some lessons. I thought I’d share some of them

I am not *the* customer (or rather the only customer)
Even though I represent the customer in different avatars (sometimes as a developer, sometimes as an office worker, sometimes just as a geek) I am not THE only customer that the product targets. When your product is going to be used by 100,000 developers/testers the average or even the predominant usage is going to be very different from what you think it will be. Sitting though an usability study is a very humbling experience. Like I believed that everyone should just be using incremental search.

Consistency is important
Geeks and bloggers tend to over-tout coolness. While cool user experience (UX) seems awesome, it is frequently overdone and what seems cool on casual usage tends to tire soon. Consistency on the other hand lets your users get on-board faster and lets them spend time doing stuff they care about and not learning things that should work automatically.

Consistency doesn’t mean that every application needs to look exactly like notepad. Expression Blend is a great example which looks refreshingly cool (appeals to the designers) and at the same time provides an experience that is consistent to other windows apps.

Learn to let go
”If there’s not something you can actively do on a project, if it’s something you can only influence and observe, then you have to learn to provide your feedback, and then let go and allow other people to fail… People don’t learn if they never make any mistakes” ~ Raymond Chen on Microspotting

Corporate software development is very different from Indie development. Large software development projects have a bunch of people/teams involved. It is not necessary that the collective opinion matches yours. At some point you need to learn to let go and do what is required. As an example I can debate on what a Debug Assert dialog should look like or do. However, there are other folks to design and think about the UX, as a developer I need to give inputs and once the call has been made it’s my job to provide the best engineering solution that implements that UX**.

 

** Do note the debug assert dialog is a fictitious example, I never worked on the IDE side.

Indic Language Input

If you have tried inputting Indian languages in Windows you know it’s a major pain. That is particularly sad because Windows comes with very good support of Indian languages. I had almost given up using my native language Bengali on a computer due to this. Even when I was creating the About Page for this blog and wanted to have a version in Bengali, I had to cut it short a lot because typing it out was so painful.

There are web-based tools like the Google Transliteration tool that works well for entering text into web-pages where they are integrated (e.g. Orkut). However, I wanted a solution that pans the desktop, so that I can use it for say writing a post using Windows Live Writer.

Enter the Microsoft Indic Language Input tool. Head over to the link and install the desktop version. You can install the various languages individually (currently Bengali, Hindi, Kannada, Malayalam, Tamil and Telugu is supported). I personally installed the Bengali and Hindi versions.

Since I am on Windows 7 which comes pre-installed with Complex language support I needn’t do anything special. However, on older OS like XP you need to do some extra steps which are available through the Getting Started link on that page.

Once you are setup you can keep the Windows Language Bar floating on the desktop. The tool extends the language bar to allow you to enter Indic languages using an English keyboard via transliteration.

Go to the application where you want to enter Indic language and then switch to Bengali (or any of the other 6 supported Indic language) using this language bar. Start typing বেঙ্গলি using English keyboard and the tool will transliterates. The moment you’d hit a word terminator like space it inserts the Bengali word.

I tried some difficult words like কিংকর্তববিমূঢ় and it worked amazingly well

I had a very good experience with the tool. The only issue I faced was that the tool was extremely slow with some WPF apps like Seesmic twitter client. However, I got to know from the dev team that they are aware of the issue (it’s for some specific WPF apps and not WPF in general). I hope they fix it before they RTM (the tool is in Beta).

Tip: You can hit alt+shift to cycle the various languages in the toolbar without having to use your mouse (which is handy if you typing using a mix of languages).

NETCF: Count your bytes correctly

I got a stress related issue reported in which the code tried allocating a 5MB array and do some processing on it but that failed with OOM (Out of Memory). It also stated that there was way more than 5 MB available on the device and surely it’s some bug in the Execution Engine.

Here’s the code.

try{
    byte[] result;
    long GlobalFileSize = 5242660;  //5MB
    result = new byte[GlobalFileSize];
    string payload = Encoding.UTF8.GetString(result, 0, result.Length);
    System.Console.WriteLine("len " + payload.Length);
}
catch (Exception e)
{
    System.Console.WriteLine("Exception " + e); 
} 

The problem is that the user didn’t count his bytes well. The array is 5MB and it actually gets allocated correctly. The problem is with the memory complexity of the UTF8.GetString which allocates further memory based on it’s input. In this particular case the allocation pattern goes something like

  5MB  -- Byte Array allocation (as expected and works)

  5MB  -- Used by GetString call
 10MB  -- Used by GetString call
  5MB  -- Used by GetString call
 10MB  -- Used by GetString call

So GetString needed a whooping 30MB and the total allocation is around 35MB which was really not available.

Morale of the story: Count your bytes well, preferably through a tool like Remote Performance Monitor

Silverlight: Where are my colors

 

The Silverlight System.Windows.Media.Colors class is a trimmer counterpart of the WPF Colors class. E.g. Colors.AliceBlue is available in WPF but not present in Silverlight. However, these standard colors are indeed available in Silverlight XAML.

In effect in Silverlight XAML you can use

<Border Background="AliceBlue" BorderBrush="Coral" BorderThickness="2" CornerRadius="10" >

However, if you try that in code it fails to compile

foo.Background = new SolidColorBrush(Colors.Coral);

This means if you ever need to use standard colors in Silverlight code you have to use RGB values, which for Coral would be something like

foo.Background = new SolidColorBrush(Color.FromArgb(255,255,127,80));

This is kind of painful. Moreover, you need to frequently be able to convert between HTML color, RGB and XAML standard color names when you are developing an Silverlight application. To make the job easier I hacked up a small Silverlight 2 app at http://www.bonggeek.com/Ag/Colors/. You can do the following with this

1. Change colors with sliders, RGB, HTML, XAML standard color names to see what the color really looks like
   
2. All the format is kept in sync, this means if you change the sliders to get to the color Salmon then the RGB value and HTML will be updated and the drop down will switch to show the selected colors name
   
3. You can easily create variants of standard color. E.g. select Salmon using the drop down and then push the sliders to get to a slightly lighter/darker shade of the color

Enjoy and extend as you please. Sources are available here.

Global variables are bad

<This post is about C++ (C# folks are saved from this pain)>

One of our devs taking care of NETCF on Nokia S60 reported that after the latest code reached their branch things are working very slow. It was observed that Garbage Collector is getting kicked in way more than it should. Investigation showed something interesting.

I added a global var gcConfig which had a fairly complex constructor and that among other things sets the various member variables like the GC trigger threshold to default value (1mb). All of these works fine on Windows variants.

However, TCPL states “It is generally best to minimize the use of global variables and in particular to limit the use of global variables requiring complicated initialization.”. This is especially true for dlls. We tend to ignore good advice sometimes :)

For Symbian OS (S60) on device complex ctors of global objects are not run (without any warning). The members are all set to 0 (default member initialization). So in the gcConfig GC-trigger was being set to 0 instead of 1mb. The allocation byte count is compared against this value to figure out when it’s time to start a GC. Since it was 0 the collection condition is being met for every allocation and hence for every allocation request GC was being fired!!!

Actually considering that even after that the app was actually running shows that we have pretty good perf ;)

A good alternative of using global vars is as follows

MyClass& useMC()
{
    static MyClass mc; // static ensures objects are not created on each call
    return mc;
}

MyClass& mc = useMC();

Do note that this has some multi-threading issue. See http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx.

.NET Compact Framework BCL < .NET BCL

Over twitter some folks are regularly discussing about the fact that there are some chunks of desktop .NET Base class library (BCL) that are missing on the .NET Compact Framework (.NETCF). So I thought I’d post the rationale behind things that are missing and what criteria is used to figure out what makes it in.

First of all, .NET and .NETCF use completely different runtimes. So the BCL code doesn’t work as is. They need to be ported over. Something being available on the desktop reduces the effort of our BCL team but still significant cost is involved in making it work over NETCF. This means that its not as if everything is available on .NETCF BCL and we cut things out (elimination process), but the other way round where we start from 0 and we need to figure out whether we can take something in. In that process we use some of the following rationale.

1. ROI: Does the user scenario that it enables on a mobile device justify the cost
   System.CodeDom.Compiler. Yea right you expected to compile on the phone didn’t you :)
   
2. Easy workaround available: If there is an acceptable workaround for a given API then it drops in priority. A trivial example could be that we ship some method overloads but not the other. E.g. Instead of shipping all overloads of Enum.Parse we drop Enum.Parse(Type, String) and keep only Enum.Parse(Type, String, Bool).
   This applies at the level of namespace or Types as well.
   
3. Lower in priority list: It needs work to get it done and it’s lower in priority than other things that is keeping the engineering team busy.
   If there are a lot of request for these features and not good/performant workarounds available then it will go up the priority list and make it to future version of NETCF
   
4. Too large to fit: Simply too large to fit into our memory limitations
   E.g. Reflection.Emit which leads to other things missing like Dynamic Language Runtime, Linq-to-SQL
   
5. No native support: It uses some underlying OS feature which is either not present on devices or is not relevant to it
   WPF, Parallel computing support

With every release developers ask for new features and we also negotiate to increase NETCF footprint budget so that we can include some (but not all) from those requests. To choose what makes it in we use some of the criteria mentioned above.

Given the system constraints under which NETCF works a vast majority of the desktop APIs will continue to be missing from NETCF. Hopefully this gives you some context behind why those are missing. If you approach NETCF simply from trying to port a desktop application then you would face some frustration on the missing surface area.

BTW: Do post your comments on this blog or on twitter (use the #netcf hashtag).

<Update: I made some updates to this based on feedback />

NETCF: GC and thread blocking

One of our customers asked us a bunch of questions on the NETCF garbage collector that qualifies as FAQ and hence I thought I’d put them up here.

Question: What is the priority of the GC thread
Answer: Unlike some variants of the desktop GC and other virtual machines (e.g. JScript) we do not have any background or timer based GC. The CLR fires GC on the same thread that tried allocation and either the allocation failed or during pre-allocation checks the CLR feels that time to run GC has come. So the priority of the GC thread is same as that of the thread that resulted in GC.

Question: Can the GC freeze managed threads that are of higher priority than the GC thread?
Answer: Yes GC can freeze managed threads which has higher priority than itself. Before actually running GC the CLR tries to go into a “safe point”. Each thread has a suspend event associated with it and this event is checked by each thread regularly. Before starting GC the CLR enumerates all managed threads and in each of them sets this event. In the next point when the thread checks and finds this event set, it blocks waiting for the event to get reset (which happens when GC is complete). This mechanism is agnostic of the relative priority of the various threads.

Question: Does it freeze all threads or only Managed threads?
Answer: The NETCF GC belongs to the category “stop-the-world GC”. It needs to freeze threads so that when it is iterating and compacting managed heap nothing on it gets modified. This is unlike some background/incremental GC supported by other virtual machines.

GC freezes only managed threads and not other native threads (e.g. COM or host-threads). However, there are two exclusions even on the managed threads

1. It doesn’t freeze the managed thread that started GC because the GC will be run on that thread (see answer to first question)
2. Managed threads that are currently executing in native p/invoke code is not frozen either. However, the moment they try to return to managed execution they get frozen. (I actually missed this subtle point in my response and Brian caught it :))

Hope this answers some of your questions. Feel free to send me any .NET Compact Framework CLR questions. I will either answer them myself or get someone else to do it for you :)

I am the Empire

5 years back exactly on this very day I walked into Cyber Towers office of Microsoft India for the first time. If someone asked me at that time how long I plan to work for Microsoft, my answer would’ve been couple of years max. I was still a bit suspicious of the evil empire and it took some time for me to realize that “I am the empire”. The 5 years has been a mind blowing journey.

Even though in our industry working for any company for a 5 year stretch is a huge thing, it doesn’t seem so in Microsoft. Our team has 4 people over 20 years and at least 8 people over 10 years.

Some random thoughts on the last 5 years

1. Made my family relocate 3 cities before settling down in Hyderabad (my wife’s threat that the next relocation would be without her helped).
2. Bought an apartment
3. I have a daughter now who was born around 3 months after I joined MS.
4. Started working in a shared office with Ankur and then worked in various cubicles. Finally I have an office.
5. 3 job designations. SDE to SDEII to Senior SDE. I am fiercely protecting the SDE suffix.
6. It’s fantastic to walk into a book store and see books on your work and see screenshots of UI you’ve designed or description of algorithms you’ve come up with.
7. 327 blog posts on blogs.msdn.com
8. I still do not use Visual Studio to edit code
9. Finally gave up on Linux even at home. Bye bye Ubuntu, welcome Windows 7
10. I have 3 Xboxes in my office and none at home
11. I use Nokia phones
12. Made fantastic friends at work and sadly few of them are left with Microsoft India (either moved to Redmond or have left MS). Hello Amit, Srivatsn, Ankur :)
13. Always wanted to attend a BillG project review but he quit
14. Got into some email wars
15. I am no longer the fire-head I used to be. I actually think before I speak.
16. Went top down from n-tier architectures (TFS), desktop applications (VSTT) and now embedded (NETCF)
17. I prefer Starbucks coffee now instead of Darjeeling tea

How does the .NET Compact Memory allocator work

As I mentioned in one of my previous posts the .NET Compact Framework uses 5 separate heaps of which one is dedicated for managed data and is called the managed heap. The .NETCF allocator, allocates pools of data from this managed heap and then sub-allocates managed objects from this pool.

This is how the process goes

	At the very beginning the allocator allocates a 64Kb pool (called the obj-pool) and ties it with the current app-domain state (AppState).
	All object allocation requests are served from this pool (Pool 0). After each allocation an internal pointer (shown in yellow) is incremented to point to the end of the last allocated object.
	Subsequent allocation is just incrementing this pointer.
	This goes on until the point where there is no more space left in the current obj-pool
	Since there is no more space left in the current pool (pool 0) a new pool (pool 1) is allocated and all subsequent object allocation requests are serviced from the new pool.

The first question I get asked at this point is what happens when one object itself is bigger than 64Kb :). The answer is that the CLR considers such objects as “huge-objects” and they are placed in their own obj-pool. This essentially means that either obj-pools are 64Kb in size and has more than one object in them or are bigger than 64Kb and has only one huge-object in it.

Object allocation speed varies a lot between whether it is being allocated from the current pool (where it is just the cost of a pointer increment) or it needs a new pool to be allocated (where there is additional cost of a 64Kb allocation). On the average managed objects are 35 bytes in size and around 1800 can fit in one pool and hence on the whole allocation speed attained is pretty good.

Verifying what we discussed above

All of the things I said above can be easily verified using the Remote Performance monitor. I wrote a small application that allocates objects in a loop and launched it under Remote Performance monitor and published the data to perfmon so that I can observe how the managed heap grows. I used the process outlined in Steven Pratschner’s blog post at http://blogs.msdn.com/stevenpr/archive/2006/04/17/577636.aspx 

Using the above mentioned mechanism I am observing the managed bytes allocated (green line) and the GC Heap (red line). You can see that the green line increases linearly and after every 64Kb the red line or the GC Heap bumps up by 64Kb as we allocate a new object pool from the heap.

Memory leak via event handlers

One of our customers recently had some interesting out-of-memory issues which I thought I’d share.

The short version

The basic problem was that they had event sinks and sources. The event sinks were disposed correctly. However, in the dispose they missed removing the event sink from the event invoker list of the source. So in effect the disposed sinks were still reachable from the event source which is still in use. So GC did not de-allocate the event sinks and lead to leaked objects.

Now the not-so-long version

Consider the following code where there are EventSource and EventSink objects. EventSource exposes the event SomeEvent which the sink listens to.

EventSink sink = new EventSink();
EventSource src = new EventSource();

src.SomeEvent += sink.EventHandler;
src.DoWork();

sink = null;
// Force collection
GC.Collect();
GC.WaitForPendingFinalizers();

For the above code if you have a finalizer for EventSink and add a breakpoint/Console.WriteLine in it, you’d see that it is never hit even though sink is clearly set to null. The reason is the 3rd line where we added sink to the invoke list of source via the += operator. So even after sink being set to null the original object is still reachable (and hence not garbage) from src.

+= is additive so as the code executes and new sinks are added the older objects still stick around resulting in working set to grow and finally lead to crash at some point.

The fix is to ensure you remove the sink with –= as in

EventSink sink = new EventSink();
EventSource src = new EventSource();
src.SomeEvent += sink.EventHandler;
src.DoWork();
src.SomeEvent -= sink.EventHandler;
sink = null;

The above code is just sample and obviously you shouldn’t do event add removal in a scattered way. Make EventSink implement IDisposable and encapsulate the += –= in ctor/dispose.