Re: [Gc] adding profiling callbacks

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).

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).

(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 :) ).

If general consensus is "happy", I'll go back and produce mergable patches.
 (excuse my newbness around this project: is the preferred method of
contribution a patch file sent to this list,  or a github pull request sent
here: https://github.com/ivmai/bdwgc  ?)

Bye, Lucas





On Mon, Jun 30, 2014 at 3:28 PM, Paul Bone <[email protected]> wrote:

> On Tue, Jul 01, 2014 at 01:11:57AM +1200, Bruce Hoult wrote:
> > Paul,
> >
> > Would Lucas's patch fill your needs? If not, what have you done
> differently?
> >
>
> It looks like it.  But I'm also curious about some of the events.  Lucas
> can
> you tell me/document what: GC_EVENT_START, GC_EVENT_RECLAIM_START,
> GC_EVENT_RECLAIM_END and GC_EVENT_END mean.  Reclaim is probably obvious
> with more knowledge about how the collector works but I'm afraid I don't
> have/don't remember that.
>
> The other thing we use with Mercury is the heap tracing code that Peter
> Wang
> wrote about on this list a few months ago.
>
>
> --
> Paul Bone
>

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc