Asp.net 4.5 "multi-core jitting" not working

Question

I'd like to take advantage of the new multi-core jitting feature in .net 4.5.

• My web.config is set to targetFramework="4.5"
• The application pool framework in IIS is set to v4.0 (from what I understand, that is correct)
• My processor is an i7 with 4 cores (or 8 with hyperthreading) - http://ark.intel.com/products/52214/

But it doesn't seem to have decreased the JIT compilation time (based on performance profiling), and I can see no evidence of any *.prof files being created in ASP.NET Temporary Files.

How can I track down the reason for this?

Answer 1

Background JIT compilation might not work in some specific scenarios. You can debug it using PerfView http://www.microsoft.com/en-us/download/details.aspx?id=28567

From the documentation, here are the main reasons:

1. When modules are loaded, a module constructor could be called, which could have side effects (even this is very rare). Thus if background JITTing would cause a module to be loaded earlier than it otherwise would be, it could expose (rare) bugs. Because background JIT had a very high compatibility bar, it protects against this by taging each method with the EXACT modules that were loaded at the time of JIT compilation, and only allows them to be background JIT compiled after all those EXACT modules were also loaded in the current run. Thus if you have a scenario (say a menu opening), where sometimes more or fewer modules are loaded (because previous user actions caused different modules to load), then background JIT may not work well.

2. If you have attached a callback to the System.Assembly.ModuleResolve event, it is possible (although extremely unlikely and very bad design) that background JITing could have side effects if the ModuleResolve callback returned different answers on the second run than it did on the first run. Because of this background JIT compilation is suspended the first time an ModuleResolve callback in invoked.

3. Because any module lookup that fails, WILL call the ModuleResolve event before it finally fails, this means that any probing for modules which fail will also inhibit background JIT compilation.

I would suggest to check if the assembly(ies) which is failing the background JIT is exposing one of these issues. To do so, start a new Collection before your application is starting, and Stop it when it's done. Don't forget to check the Background JIT option in the Advanced section.

In the JITStats section you should get something like this:

Total Number of JIT compiled methods : 10,673 
Total MSec JIT compiling : 9,873 
This process uses Background JIT compilation (System.Runtime.ProfileOptimize) 
WARNING: Background JIT aborted at 11,847.909 Msec 
The last assembly before the abort was 'NHibernate.XmlSerializers' loaded unsuccessfully at 11,793.741 
Methods Background JITTed : 0 
Percent # Methods Background JITTed : 0.0% 

Update

Related to scenario 3, in the case of ASP.NET, ASP.NET itself handles the ModuleResolve event, so any module that fails to load will cause MCJ to abort in an ASP.NET app.