JIT: don't report profile for methods with insufficient samples during prejitting#55096
JIT: don't report profile for methods with insufficient samples during prejitting#55096EgorBo merged 2 commits intodotnet:mainfrom
Conversation
|
@jakobbotsch could you please take a look? |
jakobbotsch
left a comment
There was a problem hiding this comment.
This seems fine for now, but using raw counts like this in the JIT makes me a bit nervous. E.g. instrumented counts are vastly inflated compared to sampled counts, so comparing them in a raw fashion is difficult.
Ideally this kind of filtering would happen in the training job when the .mibc files are created. We might want to revisit this when we begin consuming SPGO data.
I agree, but initially I wanted to only decrease chances to inline callees in methods with small call counts. But it makes sense only in case if profile was collected by user for his/her specific workflow so the jit can more or less trust it. But it's not the case for the default profile we ship, e.g. it reports just a few calls for "IntPtr.op_Equaliyt(long, long)`. I believe mostly those come from HelloWorld.ibc - I need to check. |
Profile for AOT is collected via a special build of an app (all methods stay in tier0 and are instrumented). Let's assume all methods in hot paths are executed at least 1000 times.
I use
entryWeight + callSiteWeight > 1000formula in order to handle hot loops inside cold methods.^ Histogram for
entryWeight + callSiteWeightfor SPC.dllThis PR drastically reduces R2R size when
--Otis passed to crossgen2 (it meansExtendedDefaultPolicyis used).New size: 10.06Mb