On Wed, Jul 2, 2008 at 3:32 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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.


There is no need for this to be in the VM.  Instead the process that runs
once the LowSpaceSemaphore is signalled should be of a very high priority
(probably above finalization but below timing priority).  It then enumerates
the runnable processes (processes waiting on semaphores are resumably not
the ones chewing up memory).  It then suspends any processes on the runnable
queues that meet certain criteria.

Something that *could* be in the VM is accounting of how much space a
process consumes.  Add a slot to each process known to the VM called e.g.
slotsAllocated.  The VM computes the slots allocated between context
switches.  This is cheap to compute because it can compute how much space
was allocated since the last garbage collection or process switch simply by
subtracting the allocation pointer at the end of the previous GC or process
switch from the current allocation pointer.  The slots allocated since the
last process switch is added to the slot in the old process and the slots
allocated count zeroed on each context switch.  We then have an accurate
measure of how much space each process has allocated.

Wen the low space process runs it simply examines the runnable processes,
checking their space allocation.  It can either maintain a per-process
allocation rate by computing the amount allocated since the last low space
signal, or it can zero the per-process allocation count at each low space
signal.

This is much more flexible and less arbitrary than having the VM do it.

Similarly a VM that does context-to-stack mapping should be able to cheaply
maintain a stack size count per process since it only has to increase or
decrease the current process's stack size on each stack page
overfow/underflow and context switch.  Traversing a stack page's frames to
get an accurate count of the number of "contexts" on each page is pretty
quick (just a walk of the frame pointer->caller frame pointer chain).
 Getting an approximation by dividing the used portion of a stack page by
the minimum frame size is even quicker.

You could then provide the image with either an accurate stack depth, or a
good approximation thereof.  That gives the low space process an easy job to
identify a potentially infinitely recursive process.


In general it is good design to put mechanism in the VM and keep policy up
in the 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080702/1b3723e7/attachment.htm