In message 4274464E.2020800@gmx.de Andreas Raab andreas.raab@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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Looks for the "Any" key.