Open caizixian opened 7 months ago
gc_end
should be OK, but there is one difficulty for gc_start
. the gc_start
trace point needs to happen before the ScheduleCollection
work packet so that the bpftrace script can start recording the events for the current GC, including the start of the ScheduleCollection
work packet. Currently, the probe!(mmtk, gc_start)
and the probe!(mmtk, gc_end)
trace points are in the coordinator thread. See:
Particularly, gc_start
happens before calling do_gc_until_completion
which adds the ScheduleCollection
work packet. After removing the coordinator thread (https://github.com/mmtk/mmtk-core/pull/1067), I moved gc_end
next to the logging in EndOfGC
(Actually I replaced the EndOfGC
packet with a function), and moved gc_start
right before scheduling the ScheduleCollection
work packet, too. Since gc_end
is at roughly the same place as the logging, it should be OK. But the place for gc_start
is not a convenient place for loading the info about pages. So I think it is easier to add a separate trace point in the ScheduleCollection
work packet.
Also note that currently the log message "[POLL] {}{} ({}/{} pages)" happens in the mutator. If we want, we can add trace point there, too. Someone may be interested in how responsive the GC is (i.e. measuring the time between triggering GC and the time when GC actually starts).
Alternatively, we can exposing an event whenever the number of reserved pages changes, and we can draw a line plot in Perfetto UI, too. It is just like the curve of the number of edges each thread is processing. But this plot will span over the execution of the whole program. I am not sure it is something GC developers are interested in, but it may be interesting anyway.
But this plot will span over the execution of the whole program. I am not sure it is something GC developers are interested in, but it may be interesting anyway.
I would disagree. Understanding the allocation behaviour (for example, how the allocation speed changes in different phases of the program) is definitely useful to GC developers.
We currently expose this via logging. It would be useful to make this available via tracepoints as well. I'm not sure whether we want to add this as extra arguments of
gc_start
andgc_end
, or as a separate tracepoint.Do you have any thought @wks ?
https://github.com/mmtk/mmtk-core/blob/092b7567fee69736b92c4a08dab89f170893ec06/src/util/heap/gc_trigger.rs#L69
https://github.com/mmtk/mmtk-core/blob/092b7567fee69736b92c4a08dab89f170893ec06/src/scheduler/gc_work.rs#L222