Morning!
Having sobered up somewhat over the night I've decided to (a) not post on osdev.org after drinking whisky and (b) make a serious, to the point reply to attempt make up for the initial one.
Your idea seems good, or would be had memory management units not been invented. The idea of storing a "backup" of memory somewhere and restoring that sounds good in concept, but there are a few problems I can think of:
* Programs are essentially state machines. They can be in different states at different times, and normally these states aren't defined explicitly in the program but rather can be observed by their behaviour, for example a program may (1) wait for input, (2) do some processing, (3) output.
If a problem occurs at a latter stage of (2), the only safe place to restore the program to is the
start of (2) - that is, a state transition boundary. You may say "Well, why's that? if I set the instruction pointer the same as it was 1 second ago, and all memory contents too, what could go wrong?". The answer to that is that no program is a "black box". Damn near everything relies on I/O, be it Oracle accepting transactions, or a CD burner burning to CD.
You only have control over the program execution and what's in RAM. You have
no control over I/O, and thus rewinding time in that respect is an impossibility, there is no way you can restore a state perfectly unless all the I/O devices (be they actual devices or remote computers) are restored to the same state. And that is just impossible.
* Yes, windows can tell you 'where' an exception occurred. I use 'where' in inverted commas because it's not actually where the problem was. For example, my program stupidly reads from a null pointer. So it tries to read the location "0x00000000". The program is killed. Where's the problem there? How do you fix it? Answer - you can't.
There are very few errors transparent enough to be recoverable, which is why most operating systems just don't even attempt to recover. They just kill the process and possibly restart it (Which is a sure-fire way of returning to a valid program state boundary - the initial one!).
Another example is a JIT compiler. These programs will deliberately cause illegal reads and writes in order to trap an exception condition, also known as "lazy compiling". It will leave an area of memory unmapped, and point pointers at it so that if those pointers are followed, a trap occurs. This means that the JIT compiler doesn't actually have to compute everything at once, rather it can wait until it's needed. In this case, how do you distinguish as to whether the trap is valid or not? How can
you, the kernel, who doesn't know anything about the program or its characteristics, make a decision on what to do? If you 'rewind' the program, the program will continue in an endless loop!
* My last point is that I think you may have things confused:
Two software apps have an incompatibility ( a system setting say ). If one (or both) bomb out because of this, they can use a predefined default from the dump in order to DYNAMICALLY adapt to the issue.
Why do you need a memory dump to obtain this behaviour? Why would the process not just get restarted in a 'failsafe' mode?
Say a program bombs for some reason, and say it was not detected in time. Say the kernel made a boo-boo and tried to write over a memory sector because it though it was orphaned from it's process (automatic memory freeing concept). Then say they both did this at once. Windows would bluescreen right?
This quote in particular harks of a lack of understanding. A program 'bombs'; I assume you mean segfaults -
what is not detected in time? what can one detect?
As to the latter half of your statement, you seem to not understand what virtual memory is about. In any case, a process itself can
never free or allocate its own memory, it must system call into the kernel to ask the kernel to do it. Only the kernel has control over the hardware page tables. The allocation/free mechanism will also be mutex-protected, so only one thread on one processor can allocate/free at any one time. So firstly the case can never happen. Secondly, only managed OS's running managed languages (such as C# or java) have inbuilt garbage collection.
The above is what makes me think that you've come up with a solution to solve a nonexistant problem, and are still backing it to the hilt instead of doing the reading you should have done in the first place before posting such gems as:
It will be called .... I already built a replacement Command Parser... I will soon create a fake screenshot of what I think it should look like.
I REALLY need help... so anyone interested PLEASE email me
Sphinx Gaming Inc., C.E.O., Founder
The last line is so pretentious it actually made me laugh out loud!
Hope this helps somewhat,
James
well... screw that plan then... I have to come up with something cool for it though. btw: I know I'm getting ahead of myself here, but I designed what it should look like, and I see it more in public, or handheld devices. Will post the image here soon.