Causes of clr ! JIT_New in PerfView CPU stack

Question

I am using PerfView to tune an application, and the second most expensive item is currently tagged as:

OTHER < < clr!JIT_New > >

at over 10% of CPU. This continues even for subsequent runs of the test case.

Can anyone identify what activities or code practices might be causing the dynamic generation of new code requiring JIT-ting?

Answer 1

JIT_New() is a helper function inside the CLR that runs whenever you create a new object in your code with the new operator. It just allocates memory from the garbage collected heap and calls the class constructor. Or in other words, it implements the Opcodes.Newobj IL instruction. Its name is a bit confusing, it doesn't have anything to do with jitting your code. Just a helper function that the jitter knows about, it compiles a call to this helper function directly into the generated machine code. JIT_Newarr1() would be another one you'd encounter, it allocates an array.

I don't know PerfView, do note that the execution time for JIT_New() may include the time needed to perform garbage collections. Which occur when the gen#0 heap is full when JIT_New() runs. Which would explain the large percentage, JIT_New() is otherwise extremely fast. Nothing much you can do about it, this is fixed overhead in any managed program.