Process migration and persistence

Daniel Waddington waddy16925 at ...9...
Thu Mar 17 19:41:10 CET 2016

Hi Norman,
Thanks for the extensive reply (I expected no less from you ;-)). I need to
think on your input. I don't have a concrete use-case yet, I'm simply
thinking about fast time-multiplexing of huge numbers (e.g., millions) of
application instances that can't all be held in memory at once and can't be
combined.  I'm thinking about how Genode/microkernels relates to unikernels
and mirage OS/jitsu objectives.


On Thu, Mar 17, 2016 at 10:07 AM, Norman Feske <norman.feske at ...1...
> wrote:

> Hi Daniel,
> great to see you back in Genode land! :-)
> > I'd like to be able to freeze a process (PD or even a vmm), make it
> > persistent, and unfreeze at some later point in time.  Does anyone have
> > suggestions/pointers on how to do this?
> This does not work out of the box but I see two principal approaches:
> 1) You can run the to-be-frozen program as a child of a custom runtime
>    environment that intercepts the program's PD, CPU, RM, and RAM
>    sessions. So the environment knows everything that goes on within
>    the program. This is what the Noux runtime is doing. Thanks to
>    this approach, we are able to implement fork on top of Genode. This
>    is actually very similar to what you want to achieve. Instead of
>    replicating the forking program, however, you would serialize/
>    unserialize this information. That said, there are some constraints
>    worth noting. Most importantly, the new process "forgets" all its
>    capabilities. So it must re-obtain them in order to work as
>    expected. In Noux processes, this is possible because we hide
>    Genode capabilities behind the POSIX API. So only the libc deals
>    with capabilities and can actively re-establish them after the
>    fork.
>    Another example to look at is the GDB monitor. Similar to Noux,
>    it intercepts the said core services. But it uses them to inspect
>    and control the to-be-debugged program.
> 2) Our general agenda is to create components as mere state
>    machines that are fed with state (e.g., using ROM sessions)
>    and propagate their results (e.g., using Report sessions). Since
>    such components don't contain unrecoverable internal state,
>    we can just kill and restart them. When presented with the
>    same imported state (aka ROM sessions) after the restart, they
>    end up in the same internal state as before. A practical
>    example of this approach is the way, the window decorator
>    interacts with the window manager in the Turmvilla scenario.
>    Here, we can dynamically replace one decorator component by
>    another implementation while retaining all of the window layout.
>    This approach just defines the problem away, which I find very
>    nice. :-)
> For complex monolithic applications with comprehensive internal state,
> there is the further option to run it with a VM (i.e., VirtualBox).
> Although we haven't tried it with our port, VirtualBox comes with the
> ability to suspend a VM to a file. I think this feature could be enabled
> in our version of VirtualBox without too much trouble.
> Can you share more details about your use case?
> Cheers
> Norman
> --
> Dr.-Ing. Norman Feske
> Genode Labs
> ·
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> _______________________________________________
> genode-main mailing list
> genode-main at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list