But there's even more process state to worry about. There are all sorts
of pieces of state scattered throughout the kernel, in different modules
and drivers, accessible via different interfaces. We mentioned the need
to save the state of open files; with Java, we need to save even more
state, including fcntl() and ioctl() status bits.
We also need to save and restore the signal actions.
Finally, for the Java native threads implementation, we need to save processor
contexts for each active Solaris lightweight process (LWP, kernel thread).
(We currently don't do this, and thus only support the Java green_threads
implementation.)
This scattered in-kernel process state is a disadvantage of this technique: if Java (or some other process we wish to checkpoint) begins using some bit of state we were previously unaware of, our checkpointer will fail; and likely in a disconcerting way: not until recovery time. The problem is that the entire set of per-process state is not gathered in one interface for easy capture. |