Hi Klaus,

   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.

On Wed, Jul 2, 2008 at 7:22 AM, Klaus D. Witzel <klaus.witzel at cobss.com>
wrote:

> On Wed, 02 Jul 2008 16:06:42 +0200, Eliot Miranda wrote:
>
>  On Wed, Jul 2, 2008 at 3:32 AM, Igor Stasenko wrote:
>>
>>  ...
>
>> 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.
>>
>
> 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!


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080702/424aee6d/attachment.htm