How should the performance counter "# of Methods Jitted" be interpreted?

Question

While trying to reproduce a reported problem with a managed nt-service, I've noticed that the performance counter "# of Methods Jitted" is constantly increasing (together with "# of IL Bytes Jitted"). The reported behavior consists of taking alot of memory (not necessarily everything available on the machine) and consuming 100% cpu. Requests to this nt-service (via wcf) often results in timeouts, ie 90+ seconds. (The requests originates from an asp.net site on the same machine.)

After 15 minute warmup time the value was 127k (3610 kb), and 246k (6427 kb) after an hour has elapsed, ie an increase of 119k jitted methods.

I do not think that it is this behavior alone that's causing the reported problem because the reported runtime before the service goes havoc is just a few hours.

However, I am still interested in how to interpreted this [apparently] ever-increasing number. While it's only 3 mb per hour, it will be 500 mb per week. And also, anyone know if the "# of IL Bytes Jitted" is subject of garbage collection?

(During the 20 minutes taken to write this post the number of methods has increased by 33k, and number of bytes with ~300k.)

Clarifications
Things that I should have mentioned the first time... ;)

• We have no code that creates, loads or unloads any appdomains.
• We're not emitting anything, and using C# 3, so no dynamic objects.
• We're using NHibernate and AutoMapper, both using reflection to solve their goals. However, I presume that those libraries behave well and wont cause this behavior. (Any tool out there that allows me to see what methods are jitted?)

Changes

• Removes the comparison between number of code lines and number of jitted methods. As Oded points out, the counter also includes methods within the .NET Framework.

Answer 1

The number of lines jitted includes framework and third party library code.

It is not C#, VB.NET lines, but CIL lines, which are many more lines - this may be enough to account for the discrepancy.

Answer 2

There could be a number of reasons why a process would keep on jitting code. If you load assemblies in specific AppDomains, the same methods will be re-jitted if you load the assemblies in another AppDomain (unless the assemblies are loaded as domain neutral).

Generating and running dynamic methods will also lead to jitting of all new methods.

As for garbage collection. The GC only cleans the managed object heap. Jitted code is stored in the code heap of the AppDomain and is thus not collected by GC. Unloading the AppDomain will get rid of the code heap for that domain.

This post has additional details http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

Update: Regarding tools

WinDbg + Sos will show you which methods have been jitted per type. Use !dumpmt -md. You can also see which modules are loaded in each AppDomain using the !dumpdomain command. However, it will probably take a bit of digging around to find the details you're looking for.