Surupa Biswas: CLR 4 - Resilient NGen with Targeted Patching
- Posted: May 28, 2009 at 11:18 AM
- 46,611 Views
- 6 Comments
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?
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?
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.
More posts in this blog
-
Shawn Farkas: CLR 4 - Inside the new Managed…
-
Surupa Biswas: CLR 4 - Resilient NGen with…
-
Ian Carmichael: The History and Future of the CLR
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
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!
Cheers!
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.
cool stuff
ngen has always been kind of a mystery to me 
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.
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