Feature #10917
closedAdd GC.stat[:total_time] when GC profiling enabled
Description
This patch includes a :total_time
value in GC.stat
as a Fixnum
of microseconds equivalent to GC::Profiler.total_time
. A non-zero value is only provided if GC profiling is enabled.
This avoids problems with GC::Profiler
's API in the presence of multiple callers. Well-behaved clients of GC::Profiler
are expected to call clear
periodically to constrain memory usage of the profiling structures. However, this causes problems when multiple callers--unaware of each other--rely on the value of GC::Profiler.total_time
being unaltered since their last clear
.
Using a single value in GC.stat
avoids this by providing a monotonically increasing count with every GC, not influenced by clear
.
Considerations and Questions
-
Because the individual GC times are potentially small, I tracked the total as a double and only convert to
Fixnum
when constructingGC.stat
's return. Is there something better I should be doing there, in light ofGC.stat
's insistence that the stats returned be if typesize_t
? -
What should I do (if anything) to cope with potential overflows? If Ruby is on a platform where
size_t
is 32 bits, we'd hit an overflow after 1.2 hours worth of cumulative GC time.
Future Directions
Is there any possibility of moving the GC timing (not the deeper profiling data) outside GC::Profiler.enable
's gating? I would love avoid clients needing to make code changes to track their GC time with my gem (newrelic_rpm).
As it stands invocation start times are held on the GC profiling structures, so it felt like a much bigger change to alter that, and I thought I'd pitch this simpler change first.
Any advice on whether that would be possible? Is timing too slow to do by default, or is the gating just an artifact of how it was implemented with GC::Profiler
?
Files