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