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 brainfvck
Recipients barry, benjamin.peterson, brainfvck, davin, lukasz.langa, methane, nascheme, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner, yselivanov
Date 2017-10-12.01:41:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507772493.85.0.213398074469.issue31558@psf.upfronthosting.co.za>
In-reply-to
Content
So what we did is:

We keep gc **disabled** on parent process and freeze after warmup, enable gc on child process.

The reason not to do a full collection is mentioned in previous comments/original ticket - (I called it) memory fragmentation.

The observation is - We keep gc disabled on both parent and child process and did a full collection before fork, it makes the shared memory shrink a lot compared to no collection. - There's no way for disabled gc to touch the head to make copy-on-write.

Of course, enable gc will make the shared memory shrink more. But the former case is accounting more than latter one.

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?
History
Date User Action Args
2017-10-12 01:41:33brainfvcksetrecipients: + brainfvck, tim.peters, barry, nascheme, rhettinger, pitrou, vstinner, benjamin.peterson, methane, lukasz.langa, serhiy.storchaka, yselivanov, davin
2017-10-12 01:41:33brainfvcksetmessageid: <1507772493.85.0.213398074469.issue31558@psf.upfronthosting.co.za>
2017-10-12 01:41:33brainfvcklinkissue31558 messages
2017-10-12 01:41:33brainfvckcreate