![(please configure the [header_logo] section in trac.ini)](/ThreadScope/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 16 and Version 17 of RTSsummaryEvents
- Timestamp:
- 12/23/11 12:42:59 (17 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RTSsummaryEvents
v16 v17 8 8 Here is a [https://github.com/Mikolaj/ThreadScope/raw/working/SummaryPanelMockup.png screenshot] 9 9 of what we can already do using the current set of events. It happens we can do as much for the whole runtime 10 as for t ime intervals in this case.10 as for the time intervals in this case. 11 11 12 12 {{{ … … 14 14 }}} 15 15 16 We need an event for each memory allocation.16 We'd need an event for each memory allocation to calculate the total allocated heap. 17 17 18 18 {{{ … … 20 20 }}} 21 21 22 An event with a summary of all copying done, after the end of each GC, probably.22 An event with a summary of all copying done, probably after the end of each GC. 23 23 24 24 {{{ … … 26 26 }}} 27 27 28 Either a separate event for that, perhaps emitted only after major GC ,when we know how much memory29 is really used by the program (the docs explain the "n samples" saying "only checked during major garbage collections").30 Or try to calculate it (how often to sample?) from all events. in particular memory deallocation events orGC memory freeing events.28 Either a separate event for that, perhaps emitted only after major GC when we know how much memory 29 is really used by the program. The docs explain the "n samples" above saying "only checked during major garbage collections". 30 Or we can try to calculate it (how often to sample?) from all events. in particular memory deallocation events and GC memory freeing events. 31 31 32 32 {{{ … … 46 46 }}} 47 47 48 Ask JaffaCake what the following formula means:48 No idea. Ask JaffaCake what the following formula means: 49 49 50 50 {{{ … … 74 74 by any thread in a single par GC. Events needed: the events added above suffice, 75 75 but quite a bit of extra state will have to be maintained when reading 76 the events. Perhaps +RTS -s could be modified to make this figure simpler?76 the events. Ask JaffaCake if +RTS -s could be modified to make this figure simpler. 77 77 78 78 {{{ … … 85 85 86 86 Ask JaffaCake how the "tasks" relate to the "threads" for which we generate 87 events. Perhapsto the existing GC events we can add the info about which task88 does the job . BTW, is the time between event GCIdle and GCWork counted87 events. For now, to the existing GC events we can add the info about which task 88 does the job, but may miss something this way. BTW, is the time between event GCIdle and GCWork counted 89 89 as GC time of the task? Generally, is GCIdle useful for us here in any way? 90 Similarly, can be calculate the MUT (elapsed) times just but taking the total 91 time a thread (or cap?) is run and subtracting the GC time and any pauses (and are all 92 pauses visible through events we have already?). 90 93 91 94 {{{
