<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 23, 2015 at 9:01 AM Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Jun 23, 2015, at 01:52 PM, Nick Coghlan wrote:<br>
<br>
>The current reference-counts-embedded-in-the-object-structs memory<br>
>layout also plays havoc with the all-or-nothing page level<br>
>copy-on-write semantics used by the fork() syscall at the operating<br>
>system layer, so some of the ideas we've been considering<br>
>(specifically, those related to moving the reference counter<br>
>bookkeeping out of the object structs themselves) would potentially<br>
>help with that as well (but would also have other hard to predict<br>
>performance consequences).<br>
<br>
A crazy offshoot idea would be something like Emacs' unexec, where during the<br>
build process you could preload a bunch of always-used immutable modules, then<br>
freeze the state in such a way that starting up again later would be much<br>
faster, because the imports (and probably more importantly, the searching)<br>
could be avoided.<br></blockquote><div><br></div><div>I actually would like something like this for Python, but I want it to work with hash randomization rather than freezing a single fixed hash seed. That means you'd need to record the location of all hash tables and cached hashes and fix them up after loading such a binary image at process start time, much like processing relocations when loading a binary executable.  Non trivial.</div><div><br></div><div>-gps</div><div><br></div></div></div>