I am a developer at Microsoft and work in the .NET Common Language Runtime (CLR) team. For the last 4 years I have been working on virtual machine technologies on a variety of form factors including desktops (Windows, Linux), tablets (Win8), gaming-consoles (Xbox 360), mobile devices (Windows Phone 7, Windows CE, Symbian).I have worked on various core pieces of the runtime including Garbage Collector, memory manager, platform abstraction layer, runtime-performance, etc.Before working on .NET I worked on Visual Studio Team Foundation Server, Visual Studio Team System, Adobe Framemaker, Adobe Acrobat, Texas Instrument's Code Composer Studio.
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
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
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
Like user code the system is also capable of pitching the shared code when there is a low memory situation on the device.
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.