Hi Anatoly, On 19 March 2014 10:42, anatoly techtonik <[email protected]> wrote: >> It's possible to do something like that in RPython, if you ignore all >> the additional complications like tracking raw-memory too; it looks >> like an infinite amount of painful work to me, but well, it's not my >> time :-) > > Fair point. =) I am thinking about bytecode machine. Virtualization > software like virtualbox allow to save state at run-time and restore it > later at the exact point - continue to run the system from the moment > it was saved. And they do this in incremental way - keeping track of > what memory and disk have been touched. > > So, can interpreter, while playing bytecode, do keep track of these > things and save/restore the state the same way? Is that possible > currently? If not, then why and what can be done?
It's not fundamentally easier or harder to do than it would be doing the same thing on CPython or any custom C program. While I can imagine coming up with a proof of concept very quickly, that would save and restore only the GC-managed objects; the real pain starts when needing to track changes done to general low-level memory, which is not possible in general. You would instead need some gross hack that copies the entire content of the memory of a process to emulate a fork(), which could also be done for CPython or any custom C program. How to do it concretely on a specific OS like Windows is left as an exercice to the reader, but as a starting point, look at how Cygwin implements fork(). The only advantage of PyPy, if you want, is that we can *add* an extra small complication on top of that, which is the aforementioned custom way to track the content of the GC objects. Given that this is hopefully the biggest part of the memory, doing so would give a boost to the performance of the fork() emulation written as described above. A bientôt, Armin. _______________________________________________ pypy-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-dev
