tuning changes -

• formally introduced the concept of BCS (Budget Computed via Survrate) and BCD (Budget Computed via DATAS) for budget tuning.
• unified below and above target code - now when we are above target we also grow based on the same formula (but with a different factor to avoid oscillation).
• the number of HC range is now limited by DATAS to be true adapating to size. Because of this we need to be very careful with the startup stage. I'm using gen1 size to gauge what the allowed budget is. Previously this just used the min size before the first gen2 happens which means we can be running much slower at the beginning. We also don't want to be too aggressive because we might be allocating too much before the first gen2 happens so I take half of gen1 size.
• recorded the last few adjustments to use make decision on such as getting the aggressive factor.
• we record 2 kinds of adjustments - adjust_hc and adjust_budget. I tried to adjust for msl wait but that didn't go very far because right now we don't have the separation between alloc heaps and collection heaps; adjust_budget is meant to be a transient state that's only there if we don't want to adjust HC right away; and if we are in this state for too long we do change the HC (and reset this state).
• computes a factor for how many GCs we allow before making the HC change for various scenarios.
• the computation of the allowed budget now takes the conserve_mem_setting into consideration so if it's more conservation we will give it less budget.
• provided a new config to specify the target tcp.

got rid of the following in DATAS - they were there as a proof of concept but really didn't work well at all -

• got rid of smoothed tcp - it really just doesn't make sense to use it. It makes the reaction delayed and in a counter-productive way.
• got rid of all of the space tuning related things which also didn't make sense. It was very dubious the way we calculated the "space cost". This made us barely reduce the number of heaps.

hopefully now the code is also much easier to read than the previous big method (which I wrote in a hurry).

exclude factors that introduce volatility in budget computation in SVR GC - these can change the budget dramatically in a very predictable way

• based on free list
• based on the LLC size - I'm seeing with the default SVR GC this makes the heap size larger on a 12-core machine than on a 28-core machine for the same workload for some aspnet benchmarks.

I'm really trying to make DATAS produce more predictable heap sizes. This is a very different philosophy from SVR GC.

diag is not done. Will come in a separate PR -

• I got rid of some fields that we currently fire in the HeapCountTuning event. but I didn't want to change the event layout as we might want to fire different info in the event.
• need to fire budget info in an event.

I'll add the comparison data tomorrow.