[pypy-dev] Rollback interpreter state to fork for unittesting

[Armin Rigo]

Hi Anatoly,

On 19 March 2014 10:42, anatoly techtonik <techtonik at gmail.com> 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.