Changes between Version 9 and Version 10 of RTSsummaryEvents

Timestamp:

12/21/11 07:53:44 (17 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

--

RTSsummaryEvents

@@ -13 +13 @@
 }}}
 
-An event with a summary of all copying done, after the end of each GC, 
+An event with a summary of all copying done, after the end of each GC, probably.
 
 {{{
@@ -19 +19 @@
 }}}
 
-Probably a separate event for that, instead of trying to calculate it from all events.
-Perhaps the event should be emitted during major GC (the docs explain the "n samples" 
-saying "only checked during major garbage collections").
+Either a separate event for that, perhaps emitted only after major GC, when we know how much memory
+is really used by the program (the docs explain the "n samples" saying "only checked during major garbage collections"). 
+Or try to calculate it from all events. in particular memory deallocation events or GC memory freeing events.
 
 {{{
@@ -27 +27 @@
 }}}
              
-We also need an event for slop, probably emitted rarely.
+We also need an extra event for slop, probably emitted rarely.
 
 {{{
@@ -39 +39 @@
 }}}
                   
-Ask JaffaCake the following formula means:
+Ask JaffaCake what the following formula means:
 
 {{{
@@ -52 +52 @@
   Gen  1         5 colls,     0 par    0.07s    0.07s     0.0149s    0.0386s
 }}}
-                              
+
+Ask JaffaCake if RequestParGC is enough to tell seq/par and why some StartGC
+follow neither RequestParGC nor RequestSeqGC (on the same capability, at least).
 Split the current GC events into generations and into seq/par
-(if RequestParGC is not enough to tell seq/par). We don't want to report
-the CPU time, only the elapsed time, and that's fine.
+(if RequestParGC is not enough to tell seq/par). Note that we don't want 
+to report the CPU time, only the elapsed time, and that's fine.
 With the current GC events only summarized information is available.