[squeak-dev] Re: Prim error returns (was Re: The Primitive: I am not a number- I am a named prim! - SqueakPeople article)

Klaus D. Witzel klaus.witzel at cobss.com
Wed Jul 2 16:05:48 UTC 2008


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.




More information about the Squeak-dev mailing list