You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GC has three mode: gcBackgroundMode, gcForceMode, gcForceBlockMode. gcBackgroundMode is triggered by sysmon and memory increasing. gcForceBlockMode is triggered by runtime.GC. I don't find any function using gcForceMode or any API exposed the ability for user to.use this mode. So why should we keep this mode to increase the complex of codes?
The text was updated successfully, but these errors were encountered:
You're right that this mode is not currently used for anything (it used to be used for sysmon GC). It could be deleted, though it's not really complicating the code in any way.
It's likely that I'll delete all of the modes as well as the code paths for gcForceMode and gcForceBlockMode once golang.org/cl/37520 is in, but feel free to send a CL deleting gcForceMode before then.
Actually, I'm wrong. gcForceMode is used. We set the mode to gcForceMode if GODEBUG=gcstoptheworld=1. And while nothing explicitly checks if mode == gcForceMode, it's important that it be different from gcBackgroundMode and gcForceBlockMode because there are checks against both of those.
At any rate, whenever I actually get around to consolidating the STW and concurrent GC paths, I might replace these mode checks with checks against debug.gcstoptheworld, at which point, all of the modes will go away. But until then, this mode is still used.
GC has three mode: gcBackgroundMode, gcForceMode, gcForceBlockMode. gcBackgroundMode is triggered by sysmon and memory increasing. gcForceBlockMode is triggered by runtime.GC. I don't find any function using gcForceMode or any API exposed the ability for user to.use this mode. So why should we keep this mode to increase the complex of codes?
The text was updated successfully, but these errors were encountered: