[CRIU] criu fails to dump JVM processes due to a half-closed socketpair()

[Pavel Emelyanov]

On 07/02/2013 07:39 PM, Florian Gross wrote:
> 
> On 02.07.2013, at 16:55, Pavel Emelyanov <xemul at parallels.com> wrote:
> 
>> Florian, I've reproduced the issue with your-like test program,
>> integrated one into our auto-test suite and (hopefully) fixed.
>> Can you check whether the current criu HEAD solves your issue
>> with Java?
> 
> I've just checked it with crtools HEAD. I'm now successfully able to restore the process 
> tree of VNC and eclipse in 1.36 seconds on my meager machine, which is highly awesome. Thanks 
> a lot! :)

You're welcome! And thanks for the bug report :)

> Contrast this with starting a new instance of eclipse (without checkpointing), which takes 
> about 29.6 seconds. That's an impressive improvement of 21.76x.

Wow, this is really awesome! We have considered "fast applications start" usage-scenario,
and having even such a preliminary measurement is really great.

> This is already plenty fast for me. However I'm curious: Have you thought about reverting a
> process (tree) back to a checkpoint without first needing to shut down the processes?

There's an item called "Apply-images" on the http://criu.org/Todo page. It's intention is
to transform an existing process in a way, described by (potentially incomplete) image files.
Presumably your case is covered by this.

> I guess only reverting those parts of process state that have been changed since the checkpoint
> instead of needing to restore everything from disk might be even faster. (The kernel changes in
> the repository to track dirty pages sound like they might be heading into that direction?)

Yes, memory tracked can help to speed things up :), but this is all "changes tracking" in 
the kernel we have. E.g. if app re-opens files we will only be able to find out what has 
changed by dumping them again and comparing.

> Best regards,
> Florian Gross

Thanks,
Pavel