It seems that sometimes getLikelyClasses API may return questionable results, e.g.:
In this case, according to the real code, MyClass1 is expected to be a dominating type with likelihood=50%. Instead, MyClass2 was reported as the most popular.
@AndyAyersMS said that it's caused by a small reservoir's size on EE side to collect PGO data (8 slots):
|
FORCEINLINE static bool CheckSample(T* pIndex, size_t* sampleIndex) |
|
{ |
|
const unsigned S = ICorJitInfo::HandleHistogram32::SIZE; |
|
const unsigned N = ICorJitInfo::HandleHistogram32::SAMPLE_INTERVAL; |
|
static_assert_no_msg(N >= S); |
|
static_assert_no_msg((std::is_same<T, uint32_t>::value || std::is_same<T, uint64_t>::value)); |
|
|
|
// If table is not yet full, just add entries in |
|
// and increment the table index. |
|
// |
|
T const index = *pIndex; |
|
|
|
if (index < S) |
|
{ |
|
*sampleIndex = static_cast<size_t>(index); |
|
*pIndex = index + 1; |
|
return true; |
|
} |
|
|
|
unsigned const x = HandleHistogramProfileRand(); |
|
|
|
// N is the sampling window size, |
|
// it should be larger than the table size. |
|
// |
|
// If we let N == count then we are building an entire |
|
// run sample -- probability of update decreases over time. |
|
// Would be a good strategy for an AOT profiler. |
|
// |
|
// But for TieredPGO we would prefer something that is more |
|
// weighted to recent observations. |
|
// |
|
// For S=4, N=128, we'll sample (on average) every 32nd call. |
|
// |
|
if ((x % N) >= S) |
|
{ |
|
return false; |
|
} |
|
|
|
*sampleIndex = static_cast<size_t>(x % S); |
|
return true; |
|
} |
