runtime: add MemStats.NumGC for API compatibility - #5590
Conversation
|
Normally when we add fields to runtime.MemStats, we try to implement them for the garbage collectors where possible. Could you add a |
|
Good call — it is now actually tracked rather than a constant zero.
The doc comment on the field no longer claims TinyGo does not track this. Rebased on dev. |
|
Can you please fix the |
Reading runtime.MemStats.NumGC is common enough in dependency code that its absence is a compile error for programs that never look at the value. Rather than add the field as a constant zero, track it: - gc_blocks: count completed cycles in runGC, so collections triggered by an allocation are counted as well as explicit runtime.GC() calls. The counter is read and written under gcLock, like the other counters beside it. - gc_boehm: report bdwgc's own gc_no from the prof_stats struct. - gc_leaking: always 0, since that collector never completes a cycle.
|
Done — the three Since that test asks you to weigh whether an increase is worth it, here is the cost rather than just the new numbers:
So roughly 8 bytes of BSS and 4–12 of code on a microcontroller. The BSS figure is 8 rather than 4 because the Worth being explicit that this is paid by every user of Happy either way; say which and I will push it. |
3 participants
runtime.MemStatsis missingNumGC, so any program that reads it fails to compile — including programs that only log it.TinyGo's GC does not count cycles, so the field stays 0 and the doc comment says exactly that rather than implying a number nobody maintains. The same approach the struct already takes for other fields it cannot fill.
Verified by building TinyGo.