This reverts commit 008a592. Bob Ippolito fixed it in a more robuset way. Applying his patch in the next commit.
by adding an impl of launchProgramForURI that works on Windows
The point time 0 of ghc-events is the start of the program and the start of the INIT phase of RTS. We would prefer the end of the INIT phase and the start of the MUT phase as the start of the maximal interval. However, there is no ghc-event event at that point and the two events currently in the middle of the INIT phase (Startup and WallClockTime) are not stable enough (Startup will be removed and WallClockTime is semantically not linked to the INIT phase in any way). So it's best to stick to the 0 point as the start of the maximal interval in TS.
…tter In particular the heap numbers are presented better. When we load eventlogs without heap/gc info then we clearly mark the things that are unavailable.
Also do a bit of tidying up of the stats collection code. The old view is not yet removed so we can compare and check it's ok. When we're happy we can remove the old one. The new presentation still needs some improvements, like formatting using Mb and with ',' for 1000 separators etc.
Previously we tried the experiment of visualising all the user events generated by Debug.Trace.traceEvent as bookmarks. This was ok but traceEvent is a bit too general, and it doesn't work for high frequency events to visualise them as bookmarks. But since it really is useful, we've got a new dedicated marker event generated by Debug.Trace.traceMarker and we now visualise these markers as bookmarks. See also ticket #27.
This uses the ghc-events finite machine that tracks Haskell tasks, their OS threads and the caps they migrate to.
This is needed to transform events (e.g., validate or assign caps to perf events) using the ghc-events finite machines (which need sorted events).
Previously, we signaled an error in such cases, that is when there's no GlobalSyncGC nor GCStatsGHC event between StartGC and EndGC for the GC in question.