Issue #19435 has been updated by ko1 (Koichi Sasada). Sorry for late response.
Yes, but unfortunately GC hooks have the adverse effect of disallowing allocation fast path, so I'd rather not go this route.
You are correct and we can ignore gc_enter/gc_exit events here. So we can avoid this demerit.
Is it so important to have in core? I think it would be useful for various application performance monitoring tools to be able to alert users on this kind of issues without having to use a C extension.
I agree it is convenient if Rails itself (or major gems) monitors this kind of counters. However if a gem monitoring this kind of counters is provided, I think there is no reason to avoid C-extension. For example, we can introduce `major_gc_oldgen_time` and so on, but I think it is too much. I think this proposal is also too much. Too trivial reason I against is we want to introduce Ractor local GC and this kind of memory space should be allocated for each ractor, and I don't want to make it bigger and bigger (but again, it is not important issue). ---------------------------------------- Feature #19435: Expose counts for each GC reason in GC.stat https://bugs.ruby-lang.org/issues/19435#change-102998 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context We recently tuned the GC settings on our monolith application because we were seeing some very long GC pauses (multiple seconds) during some requests. Very early we realized that we could know how often the GC was triggered, and how long it was taking, but we had no information as to why, hence no good way to know which specific configuration to tune. As of today, the only way to get this information is to compile Ruby with debug counters, but that's not really accessible for most users, and not very suitable to be deployed in production. So we patched our Ruby to expose counters for each specific reason in `GC.stat` and this data was extremely valuable. For instance we discovered that the number 1 cause of major GC was `shady` objects, which allowed us to both better tune or GC and to drive some targeted patches to Ruby. ### Proposal We'd like to merge the patch we used on our Ruby build. It expose 8 new keys in `GC.stat`: - `:major_gc_nofree_count` - `:major_gc_oldgen_count` - `:major_gc_shady_count` - `:major_gc_newobj_count` - `:major_gc_malloc_count` - `:major_gc_oldmalloc_count` - `:minor_gc_newobj_count` - `:minor_gc_malloc_count` Some very uncommon reasons like `force` etc are ignored as they're not valuable. Also note that sometimes multiple conditions can be met to trigger GC, in such case we my increment several counters, so the sum of `major_gc_*_count` can be higher than `major_gc_count`. Proposed patch: https://github.com/ruby/ruby/pull/7250 -- https://bugs.ruby-lang.org/