Expose counts for each GC reason in GC.stat#7250
Conversation
71686ee to
d9643e5
Compare
| if (reason & GPR_FLAG_NEWOBJ) objspace->profile.minor_gc_newobj_count++; | ||
| if (reason & GPR_FLAG_MALLOC) objspace->profile.minor_gc_malloc_count++; | ||
| if (reason & GPR_FLAG_METHOD) objspace->profile.minor_gc_method_count++; | ||
| if (reason & GPR_FLAG_CAPI) objspace->profile.minor_gc_capi_count++; | ||
| if (reason & GPR_FLAG_STRESS) objspace->profile.minor_gc_stress_count++; |
There was a problem hiding this comment.
It's misleading to call this the reason for minor GC. This is the reason for GC, which may be a major or a minor (it's a major when reason & GPR_FLAG_MAJOR_MASK, and a minor otherwise).
There was a problem hiding this comment.
You mean for stress specifically?
There was a problem hiding this comment.
To be honest, I'm not sure exposing the stress count is very helpful, same with force, we could probably just not expose these.
I simply exposed them all without thinking too much.
There was a problem hiding this comment.
No I mean for all of these. These flags tells us how the GC was started, but not what type of GC (major vs. minor). So I don't think it's correct to prefix these with minor_gc_.
There was a problem hiding this comment.
Oh, I see. I had no idea. So all of these reasons above could trigger a major?
There was a problem hiding this comment.
Hum, I just dug into this, and I'm not sure you're correct:
/* major reason */
GPR_FLAG_MAJOR_BY_NOFREE = 0x001,
GPR_FLAG_MAJOR_BY_OLDGEN = 0x002,
GPR_FLAG_MAJOR_BY_SHADY = 0x004,
GPR_FLAG_MAJOR_BY_FORCE = 0x008,
#if RGENGC_ESTIMATE_OLDMALLOC
GPR_FLAG_MAJOR_BY_OLDMALLOC = 0x020,
#endif
GPR_FLAG_MAJOR_MASK = 0x0ff,
/* gc reason */
GPR_FLAG_NEWOBJ = 0x100,
GPR_FLAG_MALLOC = 0x200,
GPR_FLAG_METHOD = 0x400,
GPR_FLAG_CAPI = 0x800,
GPR_FLAG_STRESS = 0x1000,So none of these are ever gonna match the MAJOR_GC_MASK. It is true that they might be flipped up at the same time than a major reason, hence a major will trigger, but as far as I can tell they are never the reason for a major.
There was a problem hiding this comment.
They aren't. They don't tell what kind of GC is being run. But that doesn't mean they guarantee a minor. The GC reason could cause both either a major or minor GC, so I don't think it's accurate to call it minor_gc_*_count.
There was a problem hiding this comment.
Ok, I guess that's where the misunderstanding is.
The point isn't to say a minor was triggered. I don't expect the sum of minor_reason to match minor_gc_count.
The goal here is to see how many time we reached these limits, if a major was triggered instead I still want these to be bumped because if you change the settings to avoid the major, you'd see that minor.
Does that make sense?
There was a problem hiding this comment.
Sorry, I'm getting more confused.
The point isn't to say a minor was triggered.
If a minor wasn't triggered (and a major was triggered instead), isn't it misleading to call it minor_gc_newobj_count or minor_gc_malloc_count?
|
I'm removing the following counters as I don't think they really help tuning GC in any way:
|
87717f9 to
39c43b9
Compare
39c43b9 to
901798a
Compare
[Feature #19435] This information is currently only available through debug counters which makes it unpractical to use in production. However this information is very useful to optimize GC in applications.
901798a to
f76fec8
Compare
[Feature #19435]
This information is currently only available through debug counters which makes it unpractical to use in production.
However this information is very useful to optimize GC in applications.
cc @peterzhu2118 @eightbitraptor @jasonhl