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!

/Klaus