Freigeben über

JIT ETW Inlining Event Fail Reasons

  • Artikel

This is a follow-up post  for JIT ETW tracing in .NET Framework 4.  These are some of the possible strings that might show up in FailReason field of the MethodJitInliningFailed event.  These are reasons that come from or are checked for by the VM (as compared to the JIT) and are listed in no particular order:

  • "Inlinee is NoMetadata" - this means the inlinee is not normal managed code. The most common case is dynamic methods. Another possibility is one of the many kinds of stubs the CLR uses internally for things like PInvoke marshalling, delegates, remoting, etc.
  • "Inlinee is debuggable" - the inlinee was compiled or loaded in such a way that it told the runtime not to optimize its code (C#'s /o- switch is one example).
  • "Profiler disabled inlining globally" - a profiler passed COR_PRF_DISABLE_INLINING.
  • "Profiler disabled inlining locally" - a profiler passed COR_PRF_MONITOR_JIT_COMPILATION and then set *pfShouldInline to FALSE in ICorProfilerCallback::JITInlining.
  • "Inlinee is not verifiable" - the inlinee does not have SkipVerification permission and is not verifiable. This is done so that verification exceptions are easier to debug.
  • "Inlinee is marked as no inline" - the inlinee is explicitly marked with MethodImplOptions.NoInlining, or the VM or JIT previously determined that the method would never be a good inline candidate and marked it as such to speed subsequent JITs that might try to inline the same inlinee.
  • "Inlinee requires a security object (calls Demand/Assert/Deny)" - the inlinee is marked with mdRequireSecObject. With our current implementation, such methods need their own call frame so the corresponding Assert or Deny will end at the return of the method.
  • "Inlinee is MethodImpl'd by another method within the same type" - an implementation limitation such that it can't find the right method to give to the JIT to inline (but don't worry, it still finds the right one to call). See IMetadataEmit::DefineMethodImpl for how this is done at the IL level. It is my understanding that the C# language does not allow this, but VB.NET does.
  • "Targeted Patching - Method lacks TargetedPatchingOptOutAttribute" - this relates to a new feature in CLR 4 where NGEN images are more version resilient. In a nutshell, we hope to be able to apply a patch or fix to mscorlib.dll and not have to recompile all the other native images on the machine that depend upon it. This should only apply to methods in the .NET framework class libraries because they are the only assemblies that can opt into this feature. For more information, see this previous blog post: Improvements to NGen in .NET Framework 4.
  • "Inlinee has restrictions the JIT doesn't want" - although this is in the code, in our current implementation this will never happen. It indicates that the VM needs to place a restriction on the inlinee (i.e. the inlinee can only be inlined if certain conditions are met), but the JIT doesn't allow any restrictions, so the VM has to refuse the inlining.

Comments

  • Anonymous
    November 06, 2009
    I was wondering if anyone could elaborate something for me. When running ngen.exe binding failures, ref-def mismatches, dependencies not getting resolved and a whole host of other errors are often observed. These errors happen for assemblies owned by teams inside microsoft too, like VS, Office, SQL server etc. Do these failures to generate native images classify as bugs, as in, someone somewhere forgot something or not?
  • Anonymous
    November 08, 2009
    Tanveer,Yes, indeed - there are a whole bunch of messages in the NGen output related to missing dependencies, profile data et al when installing various managed applications and frameworks. In general, as long as the compilation of an assembly doesn't fail (no "error compiling") it means a native image was successfully generated in spite of these issues (we end up with "partial native images" that fall back to JIT compilation for the "missing pieces" - assuming they're available at runtime i.e.). We still do try to look through the warnings and clean them up when possible, but they're not really what we treat as functional/correctness issues. Errors during compilation (where NGen returns -1) are definitely bugs, however.Hope that helps.Surupa BiswasCLR Codegen Team