lowspace signalling and handling issues
Tim Rowledge
tim at rowledge.org
Sun May 1 17:47:23 UTC 2005
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.
More information about the Vm-dev
mailing list