2008/7/2 John M McIntosh <johnmci at 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.

-- 
Best regards,
Igor Stasenko AKA sig.