Report reserved/total pages triggering GC and ending GC via USDT

[caizixian]

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 and gc_end, or as a separate tracepoint.

Do you have any thought @wks ?

mmtk-core/src/util/heap/gc_trigger.rs

Line 69 in 092b756

info!(

mmtk-core/src/scheduler/gc_work.rs

Line 222 in 092b756

info!(

[wks]

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:

mmtk-core/src/scheduler/controller.rs

Lines 83 to 85 in 092b756

	probe!(mmtk, gc_start);
	self.do_gc_until_completion();
	probe!(mmtk, gc_end);

Particularly, gc_start happens before calling do_gc_until_completion which adds the ScheduleCollection work packet. After removing the coordinator thread (#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.

[caizixian]

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.