Author brainfvck
Recipients barry, benjamin.peterson, brainfvck, davin, inada.naoki, lukasz.langa, nascheme, pitrou, rhettinger, serhiy.storchaka, tim.peters, vstinner, yselivanov
Date 2017-10-11.19:40:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507750828.34.0.213398074469.issue31558@psf.upfronthosting.co.za>
In-reply-to
Content
> This is only useful if the parent process has a lot of memory that's never used by the child processes right? Otherwise, you would lose via refcounting COWs.

What we saw in prod is that memory fragmentation caused by gc is the main reason of shared memory shrink.

The memory fragmentation is figured out by doing a full collection before fork and keep it disabled, it'll make a bunch of copy-on-write in child process.

This can't solve the copy-on-write caused by ref count, but we're thinking about freezing the ref count on those permanent objects too.

So this is useful if you did some warm-up work in parent process.

Also it could speedup gc if you have large amount of permanent objects.
History
Date User Action Args
2017-10-11 19:40:28brainfvcksetrecipients: + brainfvck, tim.peters, barry, nascheme, rhettinger, pitrou, vstinner, benjamin.peterson, inada.naoki, lukasz.langa, serhiy.storchaka, yselivanov, davin
2017-10-11 19:40:28brainfvcksetmessageid: <1507750828.34.0.213398074469.issue31558@psf.upfronthosting.co.za>
2017-10-11 19:40:28brainfvcklinkissue31558 messages
2017-10-11 19:40:28brainfvckcreate