Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Surupa Biswas: CLR 4 - Resilient NGen with Targeted Patching

Download

Right click “Save as…”

  • High Quality WMV (PC)
  • MP3 (Audio only)
  • MP4 (iPhone, Android)
  • Mid Quality WMV (Lo-band, Mobile)
  • WMV (WMV Video)
Surupa Biswas is a Program Manager on the CLR team working on NGen, CLR's Native Image Generator. The Native Image Generator (ngen.exe) creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.

What happens to current NGen images when you update the .NET Framework or CLR by installing a patch or new version of the framework/CLR? Do you have to NGen everything all over again? Well, yes, today you do. Today, NGen images are rigid. But this conversation is about tomorrow, beginning with CLR 4. What do you think the answer is in the future context?

Tune in. Learn about what Surupa and team will be delivering in CLR 4 to enable resilient NGen via targeted patching. This all adds up to enabling framework and CLR patching/updating without requiring the regeneration of native images already stored in the local native image cache. How does this work, exactly? What are the implications of image resiliency on the future of patching?

Tags:

Follow the Discussion

  • Paul Brucepbruce see, think, meet

    Awsome work, Surupa. Thanks for all your hard work on this, and to the rest of the CLR team. Can't wait for all these new features on 4.0!!!

    Also, very cool, to have something as intricate as a conversation about NI versioning be articulated as clearly and concisely as it was.

    Charles, book Surupa for a WM_IN show soon! Smiley

    Cheers!

  • warrenwarren atom heart mother

    I'm really glad to see some serious work has been done in the direction of making patching the .NET Framework a lot less intrusive.  A lot of IT folks get really grumbly when it's time to patch the framework, because the NGEN process will run for 10+ minutes, usually after a reboot, and quite often when the user is trying to get their day started.  

    I also have to say, Ms. Biswas is a really engaging and interesting person to listen to.  It's always a big bonus when you can not only show your passion for your work, but explain it in a very clear way without a lot of umm'ing and ahh'ing.  

  • Allan LindqvistaL_ Kinect ftw

    cool stuff Smiley ngen has always been kind of a mystery to me Smiley but the ngen code isnt diffrent from the jitted code right? is the only win in start up/load perf? [not trying to devaule that though, in asp.net esp, its important] Are there other benefits to ngening?

  • An NGen image contains code generated by the JIT compiler as well as data structures that the runtime generates (both are similar to what would be created at application runtime if the NGen image didn't exist). There are some differences in the code generated ahead of time vs. at runtime, but they're mostly minor (examples include generated code for accessing statics - at pre-compilation time we assume the module is going to be loaded as domain-neutral, the cross-module inlining rules are different (NGen rules are more conservative to allow for targeted patching), etc.). NGen enables sharing of code and runtime data structures across processes, so it typically improves both startup time (especially warm startup) and working set.

    Background information about NGen can be found in this article: http://msdn.microsoft.com/en-us/magazine/cc163610.aspx. Improvements we're making in CLR 4 are outlined here: http://blogs.msdn.com/clrcodegeneration/archive/2009/05/03/Improvements-to-NGen-in-.NET-Framework-4.aspx and those made in 3.5 SP1 here: http://msdn.microsoft.com/en-us/magazine/dd569747.aspx.

  • What are the performance benefits of running JITed code against ngened code. Are the performance improvements significant? What are the criteria to use ngen native images instead of plain JITed code?

  • As with everything related to performance, you'll want to measure. Smiley For large client applications there is often a significant startup time & working set reduction (such as a 5x reduction in warm startup time) if an application is fully NGen-ed (i.e. NGen-ed application code running against NGen-ed Framework assemblies). Some of the criteria for deciding whether to NGen your application are described here: http://blogs.msdn.com/clrcodegeneration/archive/2007/09/15/to-ngen-or-not-to-ngen.aspx.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.