Previously we would allocate objects to keep track of state for more
complicated LTTng events. Now we track state within the buffer so that
we can refer back to sizes of arrays...eliminating the need to keep
track of most state.
TraceLoadedDotNetRuntime model. These changes are aspiring to be bug for
bug compatible with the current set of working experiences within
PerfView. I have done detailed diffing of output from PerfView across the
changed scenarios: GCStats, JITStats, ServerGC*, Heap*, etc. Where
possible I compared the raw XML/HTML output between the new PerfView and
current Main PerfView. There are two differences that I am aware of: 1)
sort order on same weighted inputs (for instance 0 HeapSize processes sort
differently - no customer impact), and 2) JIT stats is more accurate
(there
was a bug in how it found methods in flight resulting in duplicated
entries).
Here is catalog of the changes
1) Moved PerfView to the new model
2) JITStats fix to more accurately identify methods that are being Jitted.
The previous code did not work correctly for nested Jitted methods (eg. A
starts jitting, B starts jitting and finishes, A finishes). A was
duplicated in this case.
3) Removed CAP from PerfView (into CAP)
4) Performance improvement to TraceLoadedDotNetRuntime. Since Stats is an
accumulator, scratch space, and stats it needs to cacluate stats on the
fly. Though internally it is never used for stats, so the previous
implementation was recacling a lot resulting in wasted time.
5) Added necessary configuration to TraceLoadedDotNetRuntime to accomodate
PerfView scenarios.
6) To work within the lifetime of Dispatchers the TraceProcess and
TraceLoadedDotNetRuntime no longer allow concurrent access. There is a
debug assert to discourage the use. If conncurrent use happens the
results will be overlapping.
TraceLoadedDotNetRuntime model. These changes are aspiring to be bug for
bug compatible with the current set of working experiences within
PerfView. I have done detailed diffing of output from PerfView across the
changed scenarios: GCStats, JITStats, ServerGC*, Heap*, etc. Where
possible I compared the raw XML/HTML output between the new PerfView and
current Main PerfView. There are two differences that I am aware of: 1)
sort order on same weighted inputs (for instance 0 HeapSize processes sort
differently - no customer impact), and 2) JIT stats is more accurate (there
was a bug in how it found methods in flight resulting in duplicated
entries).
Here is catalog of the changes
1) Moved PerfView to the new model
2) JITStats fix to more accurately identify methods that are being Jitted.
The previous code did not work correctly for nested Jitted methods (eg. A
starts jitting, B starts jitting and finishes, A finishes). A was
duplicated in this case.
3) Removed CAP from PerfView (into CAP)
4) Performance improvement to TraceLoadedDotNetRuntime. Since Stats is an
accumulator, scratch space, and stats it needs to cacluate stats on the
fly. Though internally it is never used for stats, so the previous
implementation was recacling a lot resulting in wasted time.
5) Added necessary configuration to TraceLoadedDotNetRuntime to accomodate
PerfView scenarios.
6) To work within the lifetime of Dispatchers the TraceProcess and
TraceLoadedDotNetRuntime no longer allow concurrent access. There is a
debug assert to discourage the use. If conncurrent use happens the
results will be overlapping.
This code still issues an HTTP request internally to the API part to
keep the logic decoupled. You can imagine merging this but the benefits
are likely to be little given the request will be localhost, and the
benefit is that it keeps things decoupled.
1) Fixed a build break in TraceLog.cs when Stats was renames to Stats()
2) Renamed TraceManagedProcess to TraceLoadedDotNetRuntime and changed the semantics from "is a" to "has a"
3) Renamed Enums to align with managed standards
4) Fixed callbacks. They now chain in this way:
TraceProcesses.OnProcessStart
TraceProcess.OnDotNetRuntimeLoad
TraceLoadedDotNetRuntime.GCStart/GCEnd/JITMethodStart/JITMethodEnd
5) Marked the majority of APIs as obsolete (experimental) to indicate common case from advanced.
Kaelin Hooper