On Fri, Jun 24, 2011 at 03:32:21PM +0200, Bert Freudenberg wrote:
> 
> On 24.06.2011, at 05:20, David T. Lewis wrote:
> 
> > On Thu, Jun 23, 2011 at 04:26:41PM +0200, Bert Freudenberg wrote:
> >> I often get the Finalization process when I press Cmd-.
> >> 
> >> Usually I want the UI process. But it should be possible to break into
> >> a higher-level one too, if it takes much time. Not sure if this could
> >> be made more intelligent?
> > 
> > It's a bit of a tricky problem. The interrupt key gets noticed by the
> > VM, which signals the FinalizationSemaphore, which gets noticed by the
> > finalizationProcess, which needs to figure out what process was the
> > likely cause of the user hitting the interrupt key. It's not necessarily
> > the UI process, because the problem may have originated from e.g.
> > "[Smalltalk createStackOverflow] fork".
> 
> I think you mean the InterruptSemaphore, waking up the userInterruptWatcher process.
> 
> > To me, the more interesting part of the problem is the fact that the
> > finalization process is frequently being selected as the process that
> > the user was "probably trying to interrupt". That means that the
> > finalization process is consuming so much processor resource that
> > it get interrupted instead of the actual process that the user intended
> > to interrupt with the Cmd-. key.
> > 
> > This seems to be typical of images that have accumulated a lot of
> > use and that tend to get sluggish over a long period of time. It
> > suggests some opportunity to improve the weak finalization process
> > overall. This is not a trivial problem by any means, and it has
> > been discussed before, but if I'm interpreting this correctly it
> > might be better to put some effort into trying to improve this,
> > as opposed to trying to make the user interrupt handler be smart
> > enough to avoid interrupting the finalizationProcess.
> > 
> > In terms of near-term improvements that might be possible, perhaps
> > it would help to have tools to reduce the amount of cruft that the
> > finalizationProcess needs to deal with. Various weak references
> > seem to accumulate over time, probably for no good reason, and
> > eventually this seems to lead to sluggish images and heavy loads
> > on the finalizationProcess.
> > 
> > - Dave
> 
> In my case I don't want it to ever interrupt the higher-priority "system" processes (event tickler, low space watcher, finalizer), but the "last" user process. Not quite sure how to determine that, though. 
> 
> Crazy idea: On user interrupt, sample the system for 100 ms to see which process takes up so much time. Too crazy? ;)

Not crazy at all. From the user point of view it takes hundreds of
milliseconds to respond to the interrupt key anyway. So pausing for
another 100 ms to figure out what process is currently hogging the
system would be a perfectly reasonable thing to do.

On the other hand, you might just find out that the finalizationProcess
is still the process that gets interrupted.

I note that the finalization process runs at a higher priority than
user processes, including the UI process. So if you had a runaway
UI process and also a busy finalization process, I would expect
the finalization process to be grabbing more of the processor and
thus likely to be selected in response to the interrupt key.

But I think something else may be going on here. If I modify my
finalization process to ensure that it is spending most of its
time waiting, I still find that it takes two interrupt key
presses to interrupt a createStackOverflow. In other words, the
finalization process is always being interrupted first, even if
it is not busy doing anything most of the time.

Dave