Ned Konz <ned at squeakland.org> wrote:

> On Friday 19 March 2004 10:49 am, Ned Konz wrote:
> > What happens is that checkForInterrupts is not being called in the case of
> > recursion into empty methods.
> >
> > Instead, quickCheckForInterrupts is being called, and it only decrements by
> > 1.
> 
> No, I'm wrong about that. It just takes quite a while (several seconds) to get 
> down to 0 in this case (since it starts at a big number).
> 
> Perhaps in your case you're able to run out of memory before it gets around to 
> actually checking for an interrupt.
I suspect that things like the relative performance of our two machines
and the difference in memory sytems (I have no growMemoryBy stuff) is
important here. Some more testing with timestamping logging for calls
to cFI etc has shown me that a lot of the apparent time when 'no
interrupt is picked up' is actually _after_ the out of memory error has
hapenned and the machine is busy writing the backtrace....

I can get about 700k to 1.5M recursions (depending on memory settings)
before the crash. What really bothers me is not seeing a low memory
notifier (except once). If I hit the interrupt key quickly enough
(within 1 second) I do indeed get a proper notifier. Remember, I have a
vm that hits the interrupt semaphore directly but I have to
synchronously poll in order to detect the key. Does the *nix vm have
any asynch. stuff for that? Does any platform?

Harking back a few messages, don't forget that having a timeout
semaphore will do us no good if we're not actually getting to cFI very
often. (For those of you following from the gallery, no cFI, no delay
checks)


> 
> Anyway, I recommend the addition of the check at the bottom of the fullGC(). 
> What do you think about this?
Well I was probably about to add something like that anyway in support
of the new prim calling regime but not particularly to deal with this
problem.

I really think it would be worthwhile to log the times when cFI and
error() are called; print the values of the counter and reset value and
'now'. I included a simpleminded print-every-hundred guard to avoid
swamping.

I think I've just rediscovered the blindingly obvious as well; pressing
ctl-d doesn't immediately start the recursive method; duh, there is the
Doit code to work through first which is when I can still get an
interrupt. Foo. Bum.  Maybe I'll try a prim to timestamp when the 'real'
recursion starts.

Currently I'm still of the opinion that frequent (ab)use of manually
setting interruptCounter to 0 will mess up the feedback pretty badly.
As an example to ponder, let the system sit and run the idle loop. On
my machine I'm currently zeroing the counter after every
ioRelinquishCPU in order to get mS Delay responses. If the machine is
not busy this will go around very quickly and rapidly bump the reset up
to 13million or so - and it can just keep going. I'd say we need some
more sophisticated feedback control here. Perhaps make the 'immediate
check' flagging actually set the value to -ve lots and then don't alter
the reset feedback value ?

OK, some experimental feedback:
I fudged ioBeep to timestamp instead and made my recurse methods be

!Object methodsFor: 'Camp Smalltalk' stamp: 'tpr 3/19/2004 21:24'!
recurse
self recurse! !
!Object methodsFor: 'Camp Smalltalk' stamp: 'tpr 3/19/2004 21:24'!
startRecurse
Beeper beepPrimitive.
self recurse! !

Then
1 startRecurse
does the deed. This stamps my trace with the actual time the recursion
starts and indeed I crash before any more keys are read.

If I comment out the reset feedback stuff in cFI (ie it stays fixed at
1000) I can interrupt easily and the trace reflects that. Mind you,
there are some dodgy things that happen after that. If I resume I _do_
get a lowspace notifer shortly after and ifI then abandon I get a
notifier in the middle of a Delay wait related to the finalization
loop. No response after this, as if the relevant event fetching is now
dead. Odd.

Well it's taken all day to write this (with several hours house hunting
in the middle) so enough is enough.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
It's redundant!  It's redundant!        -R. E. Dundant