[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
|