[ANN] Koans for Teaching the Basics of Smalltalk
Locked
123
123
 
|
Am 22.12.2011 22:24 schrieb "David T. Lewis" <[hidden email]>: I bet! Thanks for your endurance. Alex |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
In reply to this post by David T. Lewis
Santa hath come early this year! This is a double-win -- because we
can not only interrupt again but performance should be better too. This was for Igors attempt to improve the finalization mechanism, ironically for better performance back in 2010 I think -- and in which I was very interested because of how the hyper-activity of the finalization process was causing half of the processing time to be spent spinning through the weak references. Not creating garbage will help a lot, even if it still seems like overkill to be finalizing every single weak collection on every single incremental GC -- I ran with a 10 second delay at the end of the whileTrue loop and noticed a noticeable gain in performance.. Unfortunately there are a few processes which rely on the results of GC.. Can't wait to try this out, thanks a lot Dave! On Thu, Dec 22, 2011 at 3:24 PM, David T. Lewis <[hidden email]> wrote: > On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote: >> On 12/16/2011 3:33, Levente Uzonyi wrote: >> >On Thu, 15 Dec 2011, Christopher Oliver wrote: >> > >> >>On Thu, 15 Dec 2011 11:35:55 +0100 >> >>I added a tty output debug to >> >>MorphicProject>>interruptName:preemptedProcess:, and I found >> >>that Processor>>preemptedProcess occasionally answers the system weak >> >>array finalization process. Yikes! This isn't what we want to debug at >> >>all. Are we being adequately clever >> >>in determining which process to debug? >> > >> >I'm pretty sure that the currently running process is interrupted. After >> >GC (which happens often during calculations with LargeIntegers) this is >> >likely to be the finalization process. >> >> Correct. To make matters worse, when an interrupt is signaled in the >> midst of GC, the signal will be delivered after the GC cycle completes, >> therefore almost guaranteeing that the interrupted process will be the >> finalization process. >> >> And so the determination of the process to be interrupted is moderately >> stupid. What we'd really need to do is to start a slightly leaner >> version of CPUWatcher, i.e., instead of blindly interrupting whatever >> process is active, start sampling the running processes and after a >> short while (100-500 ms) decide which process to kick[*]. Plus, after >> that ensure that the UI is actually responsive so that the user can >> interact with the system and if not, keep kicking processes unless the >> system becomes interactive again. Alas, not a trivial task to be solved. >> >> [*] A more radical version would suspend *all* user processes and let >> the user decide which of the suspended processes to inspect. This might >> have some interesting side effects though... > > I think I found the underlying cause of all this grief, which in fact > has nothing to do with the user interrupt handler. The problem is that > the weak finalization process is very busy due to thrashing between > the VM and the image. The VM notifies the image when weak references > need to be cleaned up, and the weak finalization process responds by > creating new weak references for the VM to clean up, etc etc etc ... > > A fix is posted to the inbox in Collections-dtl.466 > > As Andreas observes, creating a smarter user interrupt handler is not > at all trivial. But creating a smarter weak finalization process is > really easy :) The solution was to move the check for VM support of new > finalization out of the finalization process, and perform the check > once at image startUp time. > > With that change in place, the following may all be interrupted in > the expected way: > > "[true] whileTrue" > "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" > "Smalltalk createStackOverflow" > "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1" > > Just for the record, this problem was a whole lot harder to figure out > than it was to explain ;-) > > Dave > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On Thu, Dec 22, 2011 at 07:19:03PM -0600, Chris Muller wrote:
> Santa hath come early this year! This is a double-win -- because we > can not only interrupt again but performance should be better too. > This was for Igors attempt to improve the finalization mechanism, > ironically for better performance back in 2010 I think -- and in which > I was very interested because of how the hyper-activity of the > finalization process was causing half of the processing time to be > spent spinning through the weak references. I hope that this hold up as a proper fix, and it certainly does need to be reviewed. But I want to be sure I do not leave any bad impression about the new finalization mechanism. Igor's improved finalization mechanism is in fact a *huge* performance win. People starting with a freshly downloaded image may not notice it, but as time goes on the benefits become more apparent. When using an image over a long period of time (as I tend to do), the accumulated load of handling weak finalization can be a real problem. Igor's new finalization mechanism addresses this very effectively, and this results in very noticable real-world performance improvements for Squeak. I think that I may have uncovered a problem in the weak finalization update process that has gone unnoticed for a long time. If so, then good, this should help the new finalization to work as intended. But kudos to Igor for implementing the weak finalization improvements, and I hope that fixing this glitch in the weak finalization process will clean up a few loose ends. Dave |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
On Thu, 22 Dec 2011 16:24:17 -0500
"David T. Lewis" <[hidden email]> wrote: > I think I found the underlying cause of all this grief, which in fact > has nothing to do with the user interrupt handler. The problem is that > the weak finalization process is very busy due to thrashing between > the VM and the image. The VM notifies the image when weak references > need to be cleaned up, and the weak finalization process responds by > creating new weak references for the VM to clean up, etc etc etc ... > > A fix is posted to the inbox in Collections-dtl.466 > > As Andreas observes, creating a smarter user interrupt handler is not > at all trivial. But creating a smarter weak finalization process is > really easy :) I look forward to trying this out. I still think down the road, we could buy some additional generality/cleverness in regards to whom we interrupt; I think this is what Elliott was suggesting, though I get nervous about looking at any commercial code (did he say that was from VW?) for intellectual property reasons. I have an idea of using small identity dictionary of interrupt actions by keystroke to use in EventSensor>>processEvents, but I need to think on this more; it's not even half baked yet. There really is a lot of indirection between seeing the key stroke and knocking down a process. Happy whatever you may celebrate! -- Christopher Oliver <[hidden email]> |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On 23 December 2011 05:19, Christopher Oliver
<[hidden email]> wrote: > On Thu, 22 Dec 2011 16:24:17 -0500 > "David T. Lewis" <[hidden email]> wrote: > >> I think I found the underlying cause of all this grief, which in fact >> has nothing to do with the user interrupt handler. The problem is that >> the weak finalization process is very busy due to thrashing between >> the VM and the image. The VM notifies the image when weak references >> need to be cleaned up, and the weak finalization process responds by >> creating new weak references for the VM to clean up, etc etc etc ... >> >> A fix is posted to the inbox in Collections-dtl.466 >> >> As Andreas observes, creating a smarter user interrupt handler is not >> at all trivial. But creating a smarter weak finalization process is >> really easy :) > > I look forward to trying this out. I still think down the road, we could buy some additional generality/cleverness > in regards to whom we interrupt; I think this is what Elliott was suggesting, though I get nervous about looking at > any commercial code (did he say that was from VW?) for intellectual property reasons. As a general principle, that's laudable. Cog is, however, MIT licensed (http://www.mirandabanda.org/cogblog/about-cog/) so in this case there's no need to fret. frank > I have an idea of using > small identity dictionary of interrupt actions by keystroke to use in EventSensor>>processEvents, but I need to > think on this more; it's not even half baked yet. There really is a lot of indirection between seeing the key stroke > and knocking down a process. > > Happy whatever you may celebrate! > > -- > Christopher Oliver <[hidden email]> > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
I've seen suspicious behavior (tough time interrupting and lots of
finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true? Cheers, Bob |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
On 12/22/2011 22:24, David T. Lewis wrote:
> I think I found the underlying cause of all this grief, which in fact > has nothing to do with the user interrupt handler. The problem is that > the weak finalization process is very busy due to thrashing between > the VM and the image. The VM notifies the image when weak references > need to be cleaned up, and the weak finalization process responds by > creating new weak references for the VM to clean up, etc etc etc ... Excellent find! Cheers, - Andreas > A fix is posted to the inbox in Collections-dtl.466 > > As Andreas observes, creating a smarter user interrupt handler is not > at all trivial. But creating a smarter weak finalization process is > really easy :) The solution was to move the check for VM support of new > finalization out of the finalization process, and perform the check > once at image startUp time. > > With that change in place, the following may all be interrupted in > the expected way: > > "[true] whileTrue" > "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" > "Smalltalk createStackOverflow" > "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1" > > Just for the record, this problem was a whole lot harder to figure out > than it was to explain ;-) > > Dave > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by Bob Arning-2
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
> I've seen suspicious behavior (tough time interrupting and lots of > finalization in MessageTally reports) in my 4.2 image, so I thought I'd > look at applying this fix. One thing I'm a little puzzled about: > HasNewFinalization is false in my image (I'm using a Cog that's a few > months old). Under what conditions is it true? I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid. This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly. WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess. A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed. Dave |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
David,
While I was a little suspicious about the close placement of the init and test, my observation was from a 4.2 image with no changes in this area. Just curious what image/vm implements this *new* finalization. Cheers, Bob On 12/23/11 10:13 AM, David T. Lewis wrote: On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid. This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly. WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess. A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed. Dave |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: > > I've seen suspicious behavior (tough time interrupting and lots of > > finalization in MessageTally reports) in my 4.2 image, so I thought I'd > > look at applying this fix. One thing I'm a little puzzled about: > > HasNewFinalization is false in my image (I'm using a Cog that's a few > > months old). Under what conditions is it true? > > I think you have spotted a timing problem here. I put the initTestPair > and checkTestPair calls together in a startUp: method, which is > wrong because it does not give the VM an opportunity to do its > updates, so the results of the test are not valid. > > This is not exactly elegant, but if you force a garbage collection > between initTestPair and checkTestPair, the test will work properly. > > WeakArray class>>startUp: resuming > resuming ifFalse: [ ^self ]. > "Check if new finalization is supported by the VM" > WeakFinalizationList initTestPair. > Smalltalk garbageCollect. > WeakFinalizationList checkTestPair. > self restartFinalizationProcess. > > A better fix is needed - sorry about that. I'm not sure if I'll > have a chance to look at this today, but the important thing is > to arrange for the check to be done when the image is started, > but not to continue repeating the test after it has been > successfully performed. The following seems to take care of the issue without requiring anything to be done in the startUp: method. WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat I'll update this in the inbox. Bob, thanks for catching the error. Dave |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by Bob Arning-2
The image side changes were part of Squeak 4.2, and VM changes happened
before that. I think that all the VMs currently in circulation will have this support, but I'm not certain of it. For the interpreter VM, the changes were introduced here: Name: VMMaker-dtl.175 Time: 25 May 2010, 8:01:19 am Ancestors: VMMaker-dtl.174 VMMaker 4.2.2 Reference Mantis 7473: VM changes for better finalization support Add Igor's VM changes to support better finalization (weak-finalizers-VM.1.cs merged with Alien support updates). The Cog VMs would have had the support added in a similar time frame, although I don't recall exactly when. HTH, Dave On Fri, Dec 23, 2011 at 10:22:25AM -0500, Bob Arning wrote: > David, > > While I was a little suspicious about the close placement of the init > and test, my observation was from a 4.2 image with no changes in this > area. Just curious what image/vm implements this *new* finalization. > > Cheers, > Bob > > > > On 12/23/11 10:13 AM, David T. Lewis wrote: > >On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: > >>I've seen suspicious behavior (tough time interrupting and lots of > >>finalization in MessageTally reports) in my 4.2 image, so I thought I'd > >>look at applying this fix. One thing I'm a little puzzled about: > >>HasNewFinalization is false in my image (I'm using a Cog that's a few > >>months old). Under what conditions is it true? > >I think you have spotted a timing problem here. I put the initTestPair > >and checkTestPair calls together in a startUp: method, which is > >wrong because it does not give the VM an opportunity to do its > >updates, so the results of the test are not valid. > > > >This is not exactly elegant, but if you force a garbage collection > >between initTestPair and checkTestPair, the test will work properly. > > > >WeakArray class>>startUp: resuming > > resuming ifFalse: [ ^self ]. > > "Check if new finalization is supported by the VM" > > WeakFinalizationList initTestPair. > > Smalltalk garbageCollect. > > WeakFinalizationList checkTestPair. > > self restartFinalizationProcess. > > > >A better fix is needed - sorry about that. I'm not sure if I'll > >have a chance to look at this today, but the important thing is > >to arrange for the check to be done when the image is started, > >but not to continue repeating the test after it has been > >successfully performed. > > > >Dave > > > > > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On Fri, 23 Dec 2011, David T. Lewis wrote:
> The image side changes were part of Squeak 4.2, and VM changes happened > before that. I think that all the VMs currently in circulation will have > this support, but I'm not certain of it. Eliot's CogVMs don't have this patch. Levente > > For the interpreter VM, the changes were introduced here: > > Name: VMMaker-dtl.175 > Time: 25 May 2010, 8:01:19 am > Ancestors: VMMaker-dtl.174 > > VMMaker 4.2.2 > Reference Mantis 7473: VM changes for better finalization support > Add Igor's VM changes to support better finalization (weak-finalizers-VM.1.cs merged with Alien support updates). > > The Cog VMs would have had the support added in a similar time > frame, although I don't recall exactly when. > > HTH, > Dave > > > On Fri, Dec 23, 2011 at 10:22:25AM -0500, Bob Arning wrote: >> David, >> >> While I was a little suspicious about the close placement of the init >> and test, my observation was from a 4.2 image with no changes in this >> area. Just curious what image/vm implements this *new* finalization. >> >> Cheers, >> Bob >> >> >> >> On 12/23/11 10:13 AM, David T. Lewis wrote: >>> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: >>>> I've seen suspicious behavior (tough time interrupting and lots of >>>> finalization in MessageTally reports) in my 4.2 image, so I thought I'd >>>> look at applying this fix. One thing I'm a little puzzled about: >>>> HasNewFinalization is false in my image (I'm using a Cog that's a few >>>> months old). Under what conditions is it true? >>> I think you have spotted a timing problem here. I put the initTestPair >>> and checkTestPair calls together in a startUp: method, which is >>> wrong because it does not give the VM an opportunity to do its >>> updates, so the results of the test are not valid. >>> >>> This is not exactly elegant, but if you force a garbage collection >>> between initTestPair and checkTestPair, the test will work properly. >>> >>> WeakArray class>>startUp: resuming >>> resuming ifFalse: [ ^self ]. >>> "Check if new finalization is supported by the VM" >>> WeakFinalizationList initTestPair. >>> Smalltalk garbageCollect. >>> WeakFinalizationList checkTestPair. >>> self restartFinalizationProcess. >>> >>> A better fix is needed - sorry about that. I'm not sure if I'll >>> have a chance to look at this today, but the important thing is >>> to arrange for the check to be done when the image is started, >>> but not to continue repeating the test after it has been >>> successfully performed. >>> >>> Dave >>> >>> >>> > >> > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
On Fri, 23 Dec 2011, David T. Lewis wrote:
> On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote: >> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: >>> I've seen suspicious behavior (tough time interrupting and lots of >>> finalization in MessageTally reports) in my 4.2 image, so I thought I'd >>> look at applying this fix. One thing I'm a little puzzled about: >>> HasNewFinalization is false in my image (I'm using a Cog that's a few >>> months old). Under what conditions is it true? >> >> I think you have spotted a timing problem here. I put the initTestPair >> and checkTestPair calls together in a startUp: method, which is >> wrong because it does not give the VM an opportunity to do its >> updates, so the results of the test are not valid. >> >> This is not exactly elegant, but if you force a garbage collection >> between initTestPair and checkTestPair, the test will work properly. >> >> WeakArray class>>startUp: resuming >> resuming ifFalse: [ ^self ]. >> "Check if new finalization is supported by the VM" >> WeakFinalizationList initTestPair. >> Smalltalk garbageCollect. >> WeakFinalizationList checkTestPair. >> self restartFinalizationProcess. >> >> A better fix is needed - sorry about that. I'm not sure if I'll >> have a chance to look at this today, but the important thing is >> to arrange for the check to be done when the image is started, >> but not to continue repeating the test after it has been >> successfully performed. > > The following seems to take care of the issue without requiring > anything to be done in the startUp: method. > > WeakArray class>>finalizationProcess > | initialized | > initialized := false. > [FinalizationSemaphore wait. > initialized ifFalse: ["check VM capability once at image startup time" > WeakFinalizationList initTestPair. > Smalltalk garbageCollect. > WeakFinalizationList checkTestPair. > initialized := true]. > FinalizationLock critical: > [FinalizationDependents do: > [ :weakDependent | > weakDependent ifNotNil: > [weakDependent finalizeValues]]] > ifError: > [:msg :rcvr | rcvr error: msg]] repeat > > I'll update this in the inbox. Bob, thanks for catching the error. There's still a very small window during startUp while the value of HasNewFinalization can be incorrect and it seems to be really hard to fix it from the image side. I don't know if this can cause any problems, but a new primitive for checking the availability would have been a better choice IMHO. Levente > > Dave > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On Fri, Dec 23, 2011 at 04:51:58PM +0100, Levente Uzonyi wrote:
> On Fri, 23 Dec 2011, David T. Lewis wrote: > > >The image side changes were part of Squeak 4.2, and VM changes happened > >before that. I think that all the VMs currently in circulation will have > >this support, but I'm not certain of it. > > Eliot's CogVMs don't have this patch. Oh! I'm afraid you are right, I did not notice that. For reference, the weak finalization enhancement with original change sets for Cog and squeak VM is on Mantis: <http://bugs.squeak.org/view.php?id=7473> On Fri, Dec 23, 2011 at 04:57:02PM +0100, Levente Uzonyi wrote: > On Fri, 23 Dec 2011, David T. Lewis wrote: > > There's still a very small window during startUp while the value of > HasNewFinalization can be incorrect and it seems to be really hard to fix > it from the image side. I don't know if this can cause any problems, but a > new primitive for checking the availability would have been a better > choice IMHO. Yes a primitive or VM parameter might have been better, although it's probably too late to worry about it now. I think that in practice this is harmless, since any problems should be corrected once the new weak finalization process has started running. But a related concern may be that the weak finalization process is terminated before the new one is started, and it is probably not a good idea to terminate that process if it might be in the middle of e.g. finalizing values in a WeakKeyDictionary. Again this is probably not an issue in practice, but it does look a bit dangerous. Dave |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by David T. Lewis
On 23.12.2011, at 16:38, David T. Lewis wrote: > On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote: >> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: >>> I've seen suspicious behavior (tough time interrupting and lots of >>> finalization in MessageTally reports) in my 4.2 image, so I thought I'd >>> look at applying this fix. One thing I'm a little puzzled about: >>> HasNewFinalization is false in my image (I'm using a Cog that's a few >>> months old). Under what conditions is it true? >> >> I think you have spotted a timing problem here. I put the initTestPair >> and checkTestPair calls together in a startUp: method, which is >> wrong because it does not give the VM an opportunity to do its >> updates, so the results of the test are not valid. >> >> This is not exactly elegant, but if you force a garbage collection >> between initTestPair and checkTestPair, the test will work properly. >> >> WeakArray class>>startUp: resuming >> resuming ifFalse: [ ^self ]. >> "Check if new finalization is supported by the VM" >> WeakFinalizationList initTestPair. >> Smalltalk garbageCollect. >> WeakFinalizationList checkTestPair. >> self restartFinalizationProcess. >> >> A better fix is needed - sorry about that. I'm not sure if I'll >> have a chance to look at this today, but the important thing is >> to arrange for the check to be done when the image is started, >> but not to continue repeating the test after it has been >> successfully performed. > > The following seems to take care of the issue without requiring > anything to be done in the startUp: method. > > WeakArray class>>finalizationProcess > | initialized | > initialized := false. > [FinalizationSemaphore wait. > initialized ifFalse: ["check VM capability once at image startup time" > WeakFinalizationList initTestPair. > Smalltalk garbageCollect. > WeakFinalizationList checkTestPair. > initialized := true]. > FinalizationLock critical: > [FinalizationDependents do: > [ :weakDependent | > weakDependent ifNotNil: > [weakDependent finalizeValues]]] > ifError: > [:msg :rcvr | rcvr error: msg]] repeat > > I'll update this in the inbox. Bob, thanks for catching the error. > > Dave Guess we should resume this discussion: This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial. How to proceed? - Bert - |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On Fri, 6 Jan 2012, Bert Freudenberg wrote:
> > On 23.12.2011, at 16:38, David T. Lewis wrote: > >> On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote: >>> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: >>>> I've seen suspicious behavior (tough time interrupting and lots of >>>> finalization in MessageTally reports) in my 4.2 image, so I thought I'd >>>> look at applying this fix. One thing I'm a little puzzled about: >>>> HasNewFinalization is false in my image (I'm using a Cog that's a few >>>> months old). Under what conditions is it true? >>> >>> I think you have spotted a timing problem here. I put the initTestPair >>> and checkTestPair calls together in a startUp: method, which is >>> wrong because it does not give the VM an opportunity to do its >>> updates, so the results of the test are not valid. >>> >>> This is not exactly elegant, but if you force a garbage collection >>> between initTestPair and checkTestPair, the test will work properly. >>> >>> WeakArray class>>startUp: resuming >>> resuming ifFalse: [ ^self ]. >>> "Check if new finalization is supported by the VM" >>> WeakFinalizationList initTestPair. >>> Smalltalk garbageCollect. >>> WeakFinalizationList checkTestPair. >>> self restartFinalizationProcess. >>> >>> A better fix is needed - sorry about that. I'm not sure if I'll >>> have a chance to look at this today, but the important thing is >>> to arrange for the check to be done when the image is started, >>> but not to continue repeating the test after it has been >>> successfully performed. >> >> The following seems to take care of the issue without requiring >> anything to be done in the startUp: method. >> >> WeakArray class>>finalizationProcess >> | initialized | >> initialized := false. >> [FinalizationSemaphore wait. >> initialized ifFalse: ["check VM capability once at image startup time" >> WeakFinalizationList initTestPair. >> Smalltalk garbageCollect. >> WeakFinalizationList checkTestPair. >> initialized := true]. >> FinalizationLock critical: >> [FinalizationDependents do: >> [ :weakDependent | >> weakDependent ifNotNil: >> [weakDependent finalizeValues]]] >> ifError: >> [:msg :rcvr | rcvr error: msg]] repeat >> >> I'll update this in the inbox. Bob, thanks for catching the error. >> >> Dave > > > > Guess we should resume this discussion: > > This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial. Do you mean that it still interrupts the finalization process first? > > How to proceed? I'd mark processes which shouldn't be interrupted by default. The easiest thing to do this is to store them in a WeakSet guarded by a Semaphore. Then define two different user interrupt methods: - one that can interrupt all processes - one that can interrupt all processes except for those, which are stored in that set. This way we could prevent interrupting system processes (finalization, low space watcher, idle process, rfb session processes, etc) when a user process gets stuck. Levente > > - Bert - > > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On 06.01.2012, at 14:15, Levente Uzonyi wrote: > On Fri, 6 Jan 2012, Bert Freudenberg wrote: > >> >> On 23.12.2011, at 16:38, David T. Lewis wrote: >> >>> On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote: >>>> On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote: >>>>> I've seen suspicious behavior (tough time interrupting and lots of >>>>> finalization in MessageTally reports) in my 4.2 image, so I thought I'd >>>>> look at applying this fix. One thing I'm a little puzzled about: >>>>> HasNewFinalization is false in my image (I'm using a Cog that's a few >>>>> months old). Under what conditions is it true? >>>> >>>> I think you have spotted a timing problem here. I put the initTestPair >>>> and checkTestPair calls together in a startUp: method, which is >>>> wrong because it does not give the VM an opportunity to do its >>>> updates, so the results of the test are not valid. >>>> >>>> This is not exactly elegant, but if you force a garbage collection >>>> between initTestPair and checkTestPair, the test will work properly. >>>> >>>> WeakArray class>>startUp: resuming >>>> resuming ifFalse: [ ^self ]. >>>> "Check if new finalization is supported by the VM" >>>> WeakFinalizationList initTestPair. >>>> Smalltalk garbageCollect. >>>> WeakFinalizationList checkTestPair. >>>> self restartFinalizationProcess. >>>> >>>> A better fix is needed - sorry about that. I'm not sure if I'll >>>> have a chance to look at this today, but the important thing is >>>> to arrange for the check to be done when the image is started, >>>> but not to continue repeating the test after it has been >>>> successfully performed. >>> >>> The following seems to take care of the issue without requiring >>> anything to be done in the startUp: method. >>> >>> WeakArray class>>finalizationProcess >>> | initialized | >>> initialized := false. >>> [FinalizationSemaphore wait. >>> initialized ifFalse: ["check VM capability once at image startup time" >>> WeakFinalizationList initTestPair. >>> Smalltalk garbageCollect. >>> WeakFinalizationList checkTestPair. >>> initialized := true]. >>> FinalizationLock critical: >>> [FinalizationDependents do: >>> [ :weakDependent | >>> weakDependent ifNotNil: >>> [weakDependent finalizeValues]]] >>> ifError: >>> [:msg :rcvr | rcvr error: msg]] repeat >>> >>> I'll update this in the inbox. Bob, thanks for catching the error. >>> >>> Dave >> >> >> >> Guess we should resume this discussion: >> >> This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial. > > Do you mean that it still interrupts the finalization process first? No, I don't get a debugger to open at all, even if I press cmd-. multiple times. Do I need a later VM? Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.128] Croquet Cog 4.0.0 Mac OS X built on Sep 28 2011 13:20:56 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) platform sources revision r2496 http://www.squeakvm.org/svn/squeak/branches/Cog CoInterpreter VMMaker.oscog-eem.128 uuid: 314823f6-cd6c-468f-9183-843b558f630b Sep 28 2011 - Bert - |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
On Fri, 6 Jan 2012, Bert Freudenberg wrote:
> > On 06.01.2012, at 14:15, Levente Uzonyi wrote: snip >> >> Do you mean that it still interrupts the finalization process first? > > No, I don't get a debugger to open at all, even if I press cmd-. multiple times. Do I need a later VM? It works on windows (with both Cog and the interpreter), so I think no. Try printing the contents of the smalltalk stacks when the interrupt fails to see what causes the problem. Levente > > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.128] Croquet Cog 4.0.0 > Mac OS X built on Sep 28 2011 13:20:56 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) > platform sources revision r2496 http://www.squeakvm.org/svn/squeak/branches/Cog > CoInterpreter VMMaker.oscog-eem.128 uuid: 314823f6-cd6c-468f-9183-843b558f630b Sep 28 2011 > > - Bert - > > > > |
Re: The broken user interrupt, or the saga of 100000 factorial.
|
|
In reply to this post by Bert Freudenberg
Hmm...
I tried this with a CogMT from the beginning of December. 1. 4.3 image with latest trunk updates 2. Removed comments in #openInterrupt:onProcess: 3. Evaluated 100000 factorial with cmd-p 4. Pressed cmd-period Sometimes I get an interrupt in factorial (although not particularly quickly). Sometimes... - the SqueakDebug.log is written right away - nothing else happens until the factorial prints out, then - debugger appears on the WeakArray finalization process Don't know why one happens vs the other. Cheers, Bob On 1/6/12 8:54 AM, Bert Freudenberg wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |