This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients barry, benjamin.peterson, brainfvck, davin, lukasz.langa, methane, nascheme, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner, yselivanov
Date 2017-10-12.04:27:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> So my understand is that gc frees some objects and makes some memory pages becomes available to allocate in child process. Allocation on the shared memory pages will cause the copy-on-write even without gc.
> Though this behavior may have better name?

OK, now I got what you're talking.
I don't know proper name about it.  I call it as "memory hole" for now.

But I don't think "memory hole" is big problem, because we already has refcount.
Say there are 100 function objects in one page, and 99 of them are never used. But when 1 of them are called, the page is unshared.

Solving memory hole issue is easy: just stop allocating new object from existing pages.
But I don't think it's worth enough because of refcount issue.

Instead of trying "share most data", I recommend to "use small number of processes" approach.

In my company, we don't use "prefork", but "--lazy-app" option of uWSGI for graceful reloading. (e.g. "afterfork")
But since we use nginx in front of uWSGI, # of uWSGI worker is just 2* CPU cores.  We can serve to massive clients from only 16~32 processes.

So I prefer optimizing normal memory usage.  It is good for all applications, not only "prefork" applications.

In this case, I'm +1 to gc.freeze() proposal because it can be used for single process applications.
Date User Action Args
2017-10-12 04:27:13methanesetrecipients: + methane, tim.peters, barry, nascheme, rhettinger, pitrou, vstinner, benjamin.peterson, lukasz.langa, serhiy.storchaka, yselivanov, davin, brainfvck
2017-10-12 04:27:13methanesetmessageid: <>
2017-10-12 04:27:13methanelinkissue31558 messages
2017-10-12 04:27:13methanecreate