lowspace signalling and handling issues

[Tim Rowledge]

In message <4274464E.2020800 at gmx.de>
          Andreas Raab <andreas.raab at gmx.de> wrote:

> Hi Tim -
>
> What am I missing? I don't remember low-space stuff - I only remember 
> interrupt-related stuff.
Handling the interrupt caused by lowspace condition being signalled - Mantis
1041.

> 
> > Depending upon the exact size of object memory in use the 200kb used as the
> > lowSpaceThreshold can be gobbled up in one swallow by the
> > initializeMemoryFirstFree: method making sure there is a byte per object
that
> > survived the markPhase. In using useUpMemory we can get to having 4 bytes of
> > free space when the next allocate is attempted.... Ka-Boom. 
> 
> Well, so don't eat up the memory. There is no reason why 
> initializeMemoryFirstFree: would have to reserve that much memory - like 
> the comment says the reserve "should" be chosen so that compactions can 
> be done in one pass but there is absolutely no such requirement. 
> Multi-pass compactions have happened in the past and there is nothing 
> wrong with them (in a low-space situation).

See my earlier point (below) about the original rationale for wanting one byte
per object to keep the multi-passness from exceeding eight.

> 
> > This assumes that we really need to have one byte per object of course. The
> > original rationale was to keep the number of compact loops down to eight
(see
> > Dan's comment in initializeMemoryFirstFree:) for Alan's large demo image.
The
> > nicest solution would be to come up with a way to do our GC & compacting
> > without needing any extra space. Commence headscratching now... John
suggested
> > making sure the fwd gets less than the byte-per-object if things are tight,
and
> > accpting the extra compaction loops.
> 
> Yes. That's the only reasonable way of dealing with it.

It's a plausible way of dealing with the immediate-crash aspect but not the
only way. And it doesn't make it much better if there isn't enough memory to
allow the notifier/debugger to do any work once the signal is raised.

> 
> > Bad news- consider Tweak. With lots of processes whizzing away, merely
stopping
> > the one that did the allocation and triggered the lowspace is not going to
be
> > much good. Stopping everything except the utterly essential stuff to debug
the
> > lowspace will be needed. Probably.
> 
> Uh, oh. Are you telling me that the "low space stuff" you are referring 
> to above actually suspends the process that triggers the low-space 
> condition?
No, it doesn't do anything like that. Take a look at the mantis 1041 commentary
to remind yourself what is going on here. (And yes, I knew about lowspace not
being a per-process issue about ten years before Squeak appeared....)

If you take another look at what I wote I think you'll see that that is exactly
what I was saying; with many processes in process, simply interrupting the one
that happened to push the allocator over the limit isn't a sufficient response.
So we're in agreement about the problem, let's try to find a good solution.
Right now I think I'll find a good solution of aqueous caffeine compounds in
elevated enthalpy dihydrogen monoxide.



tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Looks for the "Any" key.