<br><br><div class="gmail_quote">On Wed, Jul 2, 2008 at 3:32 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2008/7/2 John M McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>>:<br>
<br>
[ big snip.... ]<br>
<br>
Few thoughts, about how VM could determine what process(es) is memory<br>
hungry to kill them w/o mercy, leaving rest intact and avoid dying:<br>
<br>
add 'memory policy' slot to Process instance, which can tell VM, is<br>
given process can be killed w/o damaging most critical parts of image.</blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>This is much more flexible and less arbitrary than having the VM do it.<br><br>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.<br>
<br>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.</div><div><br>
<br>In general it is good design to put mechanism in the VM and keep policy up in the image.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Lets say, a value 0 - do not kill under any circumstances, and values<br>
> 0 is candidates for killing.<br>
Then we could assign each process a corresponding policy, and when it<br>
goes to look for a candidate for killing, VM picks a process with<br>
higher 'memory policy' slot value.<br>
<br>
The we could have most important processes have value = 0, and UI and<br>
forked processes can have value = 100+. More important than UI<br>
processes can be in the middle between 0 and 100. Another rule -<br>
automatically increment value of fork(ed) process could be useful too.<br>
In this way given slot could reflect fork depth so, one can<br>
potentially track process spawn chains.<br>
<br>
How do you think, is adding new slot to Process instance worth stability? :)<br>
<br>
One more thing, which could be useful is informing image about such<br>
unconditional termination event. Either by registering a semaphore<br>
which will be signaled upon such event, or adding some kind of<br>
#onTerminate message, so dying process can handle such event by itself<br>
and perform necessary countermeasures :)<br>
Or is there already any means how to inform another process , that<br>
some other process is terminated?<br>
>From my OS practice: OS treats processes as waitable object, so one<br>
could apply following:<br>
<br>
proc run.<br>
proc wait. "wait till terminated"<br>
<br>
This is easy to do, if process can be associated with semaphore<br>
instance. And then , in case it terminates, it signals semaphore.<br>
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div><br>