Changes between Version 22 and Version 23 of RTSsummaryEvents

Show
Ignore:
Timestamp:
01/07/12 16:01:37 (2 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

Include answers fromJaffaCake, up to par GC

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v22 v23  
    1616}}} 
    1717 
    18 We'd need an event for each memory allocation to calculate the total allocated heap. 
     18We'd need an event, emitted at each GC, with the allocation since the previous GC. 
     19(We really don't want an event for every memory allocation, that would be impractical and very slow.) 
    1920 
    2021{{{ 
     
    2223}}} 
    2324 
    24 An event with a summary of all copying done, probably after the end of each GC. 
     25An event with a summary of all copying done, emitted after the end of each GC. 
    2526 
    2627{{{ 
     
    2829}}} 
    2930 
    30 Either a separate event for that, perhaps emitted only after major GC when we know how much memory 
     31A separate event for that, perhaps emitted only after major GC when we know how much memory 
    3132is really used by the program. The docs explain the "n samples" above saying "only checked during major garbage collections".  
    32 Or we can try to calculate it (how often to sample?) from all events. in particular memory deallocation events and GC memory freeing events. 
    3333 
    3434{{{ 
     
    4242}}} 
    4343 
    44 Can probably be calculated from allocation and deallocation. 
     44The "total memory in use" is stored in the mblocks_allocated global var. 
     45Check how often it changes and emit accordingly. 
    4546 
    4647{{{ 
     
    4849}}} 
    4950                   
    50 No idea what new events we need to calculate fragmentation. Ask JaffaCake what the following formula from the RTS -s code means: 
     51Fragmentation is calculated in the RTS -s code as follows: 
    5152 
    5253{{{ 
     
    5455}}} 
    5556 
    56 in particular what is the difference between peak_mblocks_allocated and hw_alloc_blocks. 
     57so it's a difference between total memory allocated from the OS (peak_mblocks_allocated),  
     58and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks).  
     59Presumably, all the events needed so far are of the latter kind, so the former may need a new event. 
    5760 
    5861{{{ 
     
    6265}}} 
    6366 
    64 Ask JaffaCake if RequestParGC is enough to distinguish between seq and par GC and why some StartGC 
    65 follow neither RequestParGC nor RequestSeqGC (on the same capability, at least, assuming I tested it right). 
    66  
    67 We'd need to split the current GC events into generations and into seq/par 
    68 (if RequestParGC is not enough to tell seq/par). Note that we don't want  
     67The current GC events (in particular RequestParGC) seem to be enough to distinguish  
     68between seq and par GC. We'd need to split the current GC events into generations, though, 
     69to report for every generation separately. Note that we don't want  
    6970to report the CPU time, only the elapsed time, and that's fine. 
    7071