Hi Klaus,<br><br> a request: please don't change the subject to Re: foo... because it breaks threading in gmail (and I guess elsewhere). All other replies have kept the subject unchanged.<br><br><div class="gmail_quote">
On Wed, Jul 2, 2008 at 7:22 AM, Klaus D. Witzel <<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Wed, 02 Jul 2008 16:06:42 +0200, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 2, 2008 at 3:32 AM, Igor Stasenko wrote:<br>
<br>
</blockquote>
...<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
<br>
There is no need for this to be in the VM. Instead the process that runs<br>
once the LowSpaceSemaphore is signalled should be of a very high priority<br>
(probably above finalization but below timing priority). It then enumerates<br>
the runnable processes (processes waiting on semaphores are resumably not<br>
the ones chewing up memory). It then suspends any processes on the runnable<br>
queues that meet certain criteria.<br>
<br>
Something that *could* be in the VM is accounting of how much space a<br>
process consumes. Add a slot to each process known to the VM called e.g.<br>
slotsAllocated. The VM computes the slots allocated between context<br>
switches. This is cheap to compute because it can compute how much space<br>
was allocated since the last garbage collection or process switch simply by<br>
subtracting the allocation pointer at the end of the previous GC or process<br>
switch from the current allocation pointer. The slots allocated since the<br>
last process switch is added to the slot in the old process and the slots<br>
allocated count zeroed on each context switch. We then have an accurate<br>
measure of how much space each process has allocated.<br>
</blockquote>
<br>
This is a very interesting point, and I would like to see memory consumption per process, that'd be great! But I'm not quite sure I understand how to balance the value of that slot, i.e. how freed space is subtracted. Could you elaborate a bit on this? Thank you!</blockquote>
<div><br>The slot only measures allocations. We never subtract freed space. We don't know which processes the space freed during a garbage collection "belongs to" (were allocated by). But we don't need to know this. The heuristic to determine which processes should be suspended to stop run-away space allocation is that if a process has allocated a lot in recent time then it is likely to continue to do so. A process can't create lots of retained objects without allocating lots of objects. So while this scheme may find false positives, processes which allocate a lot but don't retain the storage, but it will find the processes that allocate a lot and do retain the storage allocated. Since the scheme is intended to stop computation before a fatal evet (running ojut of storage) these false positives are acceptable.<br>
<br>Of course this heuristic is easy to fool if one constructs a pool of processes that conspire to pass the task of allocating space amongst themselves, so that by the time the system gets around to suspending an offending process it has passed the responsibility of behaving badly to another process, but that's a very artificial example.<br>
<br></div></div>