> > > > Maybe we can define a new executable format for it to work ;-)
Unfortunately, anything that's kernel state, kernel-state-dependent, or
interacting with another process would take major recoding to restore
properly, either on the part of the application or for all libc and the
kernel and all other applications and... Things like open files, etc.,
would be a pain to restore transparently; so far there's no telling a
prioiri what bytes are libc-internal data and which are
program-accessible, let alone what those libc-internal bytes mean and
how to change them due to the shutdown/restart...
> > > This would be practically impossible as you'd have to load the program
> > > into the exact same memory space or all of its pointers would be bad...
> > > Memory fragmentation issues would make it very hard to get any program to
> > > occupy the exact same space it did before.
*ahem* Two words: virtual memory. The only fragmentation it'll suffer
from will be from its own malloc/free sequence, assuming sbrk gives you
new hunks of memory in the same virtual addresses regardless of whether
you grab it one page at a time or all at once.
> > > The only way to really reload anything would be to dump the entire system
> > > memory to a file and reload that. This could be useful if you wanted to do
> > > something like boot into another operating system, or halt your computer
> > > for whatever reason.
You have this point correct.
> > Hmm, I'm suprised that other OS's can't do this (or can you keep a totally
> > swaped out process "running" over a reboot ?), I would have thought that
> > an OS that needs a 'shutdown -r now' in it's crontab to avoid running out
> > of memory due to leaks.
A buzzword already includes that: "persistent objects".
> > > (Of course, real Linux users never reboot or shut down, except for a
> > > hardware or kernel upgrade ;)
> > Don't forget power failure, and electrical storms ;)
Power failure, and lightning hits. We either spend $15 on a power strip
with a weenie little surge protector on the phone line and self-insure
our cheap-but-insanely-powerful 386's, or we spend enough money on
equipment to justify a UPS...
> When processes allocate memory, they can get it from anywhere in the
> memory space... There isn't any mechanism to ensure that each program's
> memory segment is continuous. When the program restarts, something else
> might have taken up one of the blocks that it wants to get... So the
> kernel would have to be modified to set aside whatever space a program
> that needs to be restarted would allocate.
That's not the problem, again assuming that the sbrk ("gimme more
memory!") system call always extends the process's VM space in a way
independent of how many times it was called...
> This would be much easier on a system where each program has a specified
> chunk of memory (such as a Mac). Of course, this is very inefficient as
> each program holds aside memory that no other program can get at. (Then
> you end up with things like RAM Doubler to reclaim these unused chunks :)
The real problems would still remain, and you couldn't restore two
programs which had overlapping spaces under such a system.
Keith (TA for an OS class)
-- "It moved faster. I swear, they are evolving right before my eyes. If you see something this big, with eight legs coming your way, let me know; I have to kill it before it develops language skills." --- Ambassador Londo Mollari, in 'Sic Transit Vir' (Babylon 5)