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.
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.
I validated this change by serializing the TraceProcess as created by TraceLog and ProcessComputer - they produce differenet results. ProcessComputer does not properly set Start/End time, and only has a partial ability to set Is64bit, ParentID, and CpuMSec.
As a step towards the *Computer processing model, here is the ProcessComputer. It is a duplication (ugh, though Vance and I agreed this is the right first step) from TraceLog. The original TraceProcess was expanded to include ClrRuntimeVersion and ClrStartupFlags to accomodate GC/JIT requirements. In addition, there was some small tweaks in TraceProcess in order to accomodate a null TraceLog (the predominate case for ProcessComputer and a non-private setter of certain properties).
I validated this change by serializing the TraceProcess as created by TraceLog and ProcessComputer - they produce differenet results. ProcessComputer does not properly set Start/End time, and only has a partial ability to set Is64bit, ParentID, and CpuMSec.
Enabled the proposed TraceProcess extension model for exposing Managed concepts. This change includes:
1. Extension methods for TraceProcesses, TraceProcess
2. Creation of TraceManagedProcess
3. And the details of how to expose GC and JIT details from etl files.
This change has duplicated code from TraceLog.cs. The goal with this change is to be an stepping stone between the current paradigm (where all this code lives in TraceLog and PerfView) to a world where there are Process, Thread, Module, Managed concepts hanging off of Source.
Reverted TraceLog.cs back to the original commit before these changes.
Accomodated feedback on PR.
Remove ProcessComputer
I validated this change by serializing the TraceProcess as created by TraceLog and ProcessComputer - they produce differenet results. ProcessComputer does not properly set Start/End time, and only has a partial ability to set Is64bit, ParentID, and CpuMSec.
As a step towards the *Computer processing model, here is the ProcessComputer. It is a duplication (ugh, though Vance and I agreed this is the right first step) from TraceLog. The original TraceProcess was expanded to include ClrRuntimeVersion and ClrStartupFlags to accomodate GC/JIT requirements. In addition, there was some small tweaks in TraceProcess in order to accomodate a null TraceLog (the predominate case for ProcessComputer and a non-private setter of certain properties).
I validated this change by serializing the TraceProcess as created by TraceLog and ProcessComputer - they produce differenet results. ProcessComputer does not properly set Start/End time, and only has a partial ability to set Is64bit, ParentID, and CpuMSec.
Enabled the proposed TraceProcess extension model for exposing Managed concepts. This change includes:
1. Extension methods for TraceProcesses, TraceProcess
2. Creation of TraceManagedProcess
3. And the details of how to expose GC and JIT details from etl files.
This change has duplicated code from TraceLog.cs. The goal with this change is to be an stepping stone between the current paradigm (where all this code lives in TraceLog and PerfView) to a world where there are Process, Thread, Module, Managed concepts hanging off of Source.
I validated this change by serializing the TraceProcess as created by TraceLog and ProcessComputer - they produce differenet results. ProcessComputer does not properly set Start/End time, and only has a partial ability to set Is64bit, ParentID, and CpuMSec.
The .NET FX version checking is built in such a way that it requires changes every time a new version is released. There are places in the GcStats that are possibily still not correct given the current version checking, but I did not observe an issue and have no direct evidence it is wrong, so I did not change them.
Per recommendation, I have realigned the code to enable better error checking and to ensure that future versions do not instantly break.
Bugs fixes:
1. Memory Pressure is now accurate (eg. it was removed)
2. Silverlight and .NET 4.5.2 traces process properly
3. GenData's fields envolved but the parsing did not, it is not accurate.
Testing:
SL 5, .NET 4.0 x86/x64, 4.5 x86/x64, 4.5.2 x86/x64, 4.6.1 x86/x64, 4.6.2 x86/x64
Inspected all events
Opened GCStats
Did a text diff between modified and non-modified
1) Added comments to CondemnReasons0 (the generation number) and CondemnReasons1 (the condition). The decoder for these lives in GcStats.cs - I contemplated moving here, but chose to not disturb working code.
2) Changed the return types for *Mechanism to return an enum type.
Moved from using a double to track major.minor to a seperate int MinorVersion.
Added back the more precise FreeList check for versions that have access to this data
Jeff Schwartz