Hi Eliot,
on Wed, 02 Jul 2008 17:40:05 +0200, you wrote:
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.
No, I didn't change the subject line. I replied to your
- http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/129727.html
and here's what the list server received from me
- http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/129731.html
and the gmane NNTP service that I'm using shows the same. Perhaps something happened on your gateway. Anyways.
On Wed, Jul 2, 2008 at 7:22 AM, Klaus D. Witzel wrote:
On Wed, 02 Jul 2008 16:06:42 +0200, Eliot Miranda wrote:
...
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.
Okay, I see what you mean. Thank you.
/Klaus
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.