Track GC stats

[rwstauner]

We should update the harness to collect GC.stat(:time) and possibly :minor_gc_count, :major_gc_count, and maybe things like total_allocated_objects

@tenderworks observed that at the start of 3.4.0dev the chunkypng was spending about 100ms in GC.
On the latest master (around "b182f2a04520a0138992b27f9e6bfd15bdfd6f96") it is spending 130ms in GC.

We should decide if there's anything else we'd like to add to the harness and start collecting the data.
Then we can decide how we might want to visualize it:

• If we collect multiple numbers we could probably use another table.
• Do we just want to add a bar chart for it?
• Do we want to include gc time in any of our other calculations?

We already have an "over time" view of some of the yjit stats:
https://speed.yjit.org/stats-timeline.html#side_exits+overall-mean+activerecord+liquid-render+optcarrot+railsbench
Maybe we'd want to add this to that list.

[maximecb]

Does GC.stat product a dict like RubyVM::YJIT.runtime_stats? If so, I would say collect all the GC stats, not just some of them. If not, then maybe we should make it return a dict 😅 (though that could be a separate project done by someone else).

We should decide if there's anything else we'd like to add to the harness and start collecting the data.
Then we can decide how we might want to visualize it

I want to minimize the number of things we display on the front page because IMO it helps to focus attention to key metrics rather than overwhelm people with tons of graphs. I would also prefer for speed.yjit.org to remain primarily focused on YJIT rather than a generic tool to benchmark and track everything, because my experience is that trying to accommodate every possible use case only leads to a worse product.

We already have an "over time" view of some of the yjit stats:
https://speed.yjit.org/stats-timeline.html#side_exits+overall-mean+activerecord+liquid-render+optcarrot+railsbench
Maybe we'd want to add this to that list.

I think this makes the most sense. The over time view could probably use some UI improvements, but it seems logical that we should be able to plot any of the stats/metrics that we have over time.

[rwstauner]

Yes, GC.stat without args produces a hash:

{:count=>34,
 :time=>38,
 :marking_time=>28,
 :sweeping_time=>10,
 :heap_allocated_pages=>99,
 :heap_sorted_length=>243,
 :heap_allocatable_pages=>144,
 :heap_available_slots=>99754,
 :heap_live_slots=>90526,
 :heap_free_slots=>9228,
 :heap_final_slots=>0,
 :heap_marked_slots=>67720,
 :heap_eden_pages=>99,
 :heap_tomb_pages=>0,
 :total_allocated_pages=>99,
 :total_freed_pages=>0,
 :total_allocated_objects=>371130,
 :total_freed_objects=>280604,
 :malloc_increase_bytes=>193808,
 :malloc_increase_bytes_limit=>16777216,
 :minor_gc_count=>27,
 :major_gc_count=>7,
 :compact_count=>0,
 :read_barrier_faults=>0,
 :total_moved_objects=>0,
 :remembered_wb_unprotected_objects=>0,
 :remembered_wb_unprotected_objects_limit=>512,
 :old_objects=>60221,
 :old_objects_limit=>102568,
 :oldmalloc_increase_bytes=>416592,
 :oldmalloc_increase_bytes_limit=>16777216}

We can grab that when we get the YJIT runtime stats

[rwstauner]

Agreed, we certainly don't need a new front page graph for this, just something on the details or history pages.