Re: [Gc] adding profiling callbacks
Paul Bone <[email protected]> Tue, 1 Jul 2014 10:30:29 +1000
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <20140701003028.GQ30547@durif> |
On Mon, Jun 30, 2014 at 05:36:55PM +0200, Lucas Meijer wrote: > Hi all, > > @Paul: GC_EVENT_RECLAIM_START gets sent when marking is finished, and > sweeping starts. > (implementation not actually in this patch. should the maintainers decide > "yeah we'd take this functionality", I'll produce a complete patch with all > these events implemented). Okay cool. > The ones I assume would generate most discussion are these: > > + GC_EVENT_SUSPENDED_THREAD, > + GC_EVENT_UNSUSPENDED_THREAD, > > which would be implemented in each OS' pthreads_stop_world.c like file, > and which casts whatever is the platform specific thread identifier into a > void* into the callback signature (as the data argument). In Mercury I implemented something similar, but I determined the identity of the thread (I wanted to find the thread's logging buffer so I could lock that it was being suspended) by simply using thread local storage. A thread identifier will also work / could be useful. > (FYI: we use these thread suspension callbacks to be able to visualize in > our profiler which thread is doing the actual GC, but also which threads > were stopped to allow to the gc to run (and therefor also visualize which > threads were not stopped :) ). Same, In particular I wanted to calculate the amount of real time spent running the application vs marking. Also I wanted to measure how long it took for threads to be suspended and resumed, if it happens often then this latency could add up. -- Paul Bone