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 issue was twofold.
First we were opening ZIP files in exclusive mode when reading, that is bad, use ZipFile.Open which does the right thing (allows other simultaneous readers)
However a related issue is that we did not close the ZIP file when the CTF open failed. This left the file open so that the next open (to open stacks) would fail.
Vance Morrison