2008/7/2 John M McIntosh johnmci@smalltalkconsulting.com:
[ big snip.... ]
Few thoughts, about how VM could determine what process(es) is memory hungry to kill them w/o mercy, leaving rest intact and avoid dying:
add 'memory policy' slot to Process instance, which can tell VM, is given process can be killed w/o damaging most critical parts of image.
Lets say, a value 0 - do not kill under any circumstances, and values
0 is candidates for killing.
Then we could assign each process a corresponding policy, and when it goes to look for a candidate for killing, VM picks a process with higher 'memory policy' slot value.
The we could have most important processes have value = 0, and UI and forked processes can have value = 100+. More important than UI processes can be in the middle between 0 and 100. Another rule - automatically increment value of fork(ed) process could be useful too. In this way given slot could reflect fork depth so, one can potentially track process spawn chains.
How do you think, is adding new slot to Process instance worth stability? :)
One more thing, which could be useful is informing image about such unconditional termination event. Either by registering a semaphore which will be signaled upon such event, or adding some kind of #onTerminate message, so dying process can handle such event by itself and perform necessary countermeasures :) Or is there already any means how to inform another process , that some other process is terminated?
From my OS practice: OS treats processes as waitable object, so one
could apply following:
proc run. proc wait. "wait till terminated"
This is easy to do, if process can be associated with semaphore instance. And then , in case it terminates, it signals semaphore.