Changes between Version 22 and Version 23 of RTSsummaryEvents

Timestamp:

01/07/12 16:01:37 (17 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

Include answers fromJaffaCake, up to par GC

RTSsummaryEvents

@@ -16 +16 @@
 }}}
 
-We'd need an event for each memory allocation to calculate the total allocated heap.
+We'd need an event, emitted at each GC, with the allocation since the previous GC.
+(We really don't want an event for every memory allocation, that would be impractical and very slow.)
 
 {{{
@@ -22 +23 @@
 }}}
 
-An event with a summary of all copying done, probably after the end of each GC.
+An event with a summary of all copying done, emitted after the end of each GC.
 
 {{{
@@ -28 +29 @@
 }}}
 
-Either a separate event for that, perhaps emitted only after major GC when we know how much memory
+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" above saying "only checked during major garbage collections". 
-Or we can try to calculate it (how often to sample?) from all events. in particular memory deallocation events and GC memory freeing events.
 
 {{{
@@ -42 +42 @@
 }}}
 
-Can probably be calculated from allocation and deallocation.
+The "total memory in use" is stored in the mblocks_allocated global var.
+Check how often it changes and emit accordingly.
 
 {{{
@@ -48 +49 @@
 }}}
                   
-No idea what new events we need to calculate fragmentation. Ask JaffaCake what the following formula from the RTS -s code means:
+Fragmentation is calculated in the RTS -s code as follows:
 
 {{{
@@ -54 +55 @@
 }}}
 
-in particular what is the difference between peak_mblocks_allocated and hw_alloc_blocks.
+so it's a difference between total memory allocated from the OS (peak_mblocks_allocated), 
+and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks). 
+Presumably, all the events needed so far are of the latter kind, so the former may need a new event.
 
 {{{
@@ -62 +65 @@
 }}}
 
-Ask JaffaCake if RequestParGC is enough to distinguish between seq and par GC and why some StartGC
-follow neither RequestParGC nor RequestSeqGC (on the same capability, at least, assuming I tested it right).
-
-We'd need to split the current GC events into generations and into seq/par
-(if RequestParGC is not enough to tell seq/par). Note that we don't want 
+The current GC events (in particular RequestParGC) seem to be enough to distinguish 
+between seq and par GC. We'd need to split the current GC events into generations, though,
+to report for every generation separately. Note that we don't want 
 to report the CPU time, only the elapsed time, and that's fine.