Re: [Pharo-project] 12186 image quit problem
Igor Is it also related to http://code.google.com/p/pharo/issues/detail?id=3048 too? Stef
with the MCMethodDefinition>>shutdown hack it work well
On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
Is it also related to     http://code.google.com/p/pharo/issues/detail?id=3048 too?
related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock.
Stef
with the MCMethodDefinition>>shutdown hack it work well
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Sat, 9 Oct 2010, Igor Stasenko wrote:
On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Igor
Is it also related to     http://code.google.com/p/pharo/issues/detail?id=3048 too?
related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock. It's probably easy to find the cause of the deadlock if you're able to print the stacks. Levente
Stef
with the MCMethodDefinition>>shutdown hack it work well
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Saturday, October 09, 2010 11:38 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
Is it also related to http://code.google.com/p/pharo/issues/detail?id=3048 too?
related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock.
Stef
with the MCMethodDefinition>>shutdown hack it work well
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
Sig,
Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated.
The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :)
The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate.
But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ siguctua@gmail.com] Sent: Saturday, October 09, 2010 11:38 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem
On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
Is it also related to http://code.google.com/p/pharo/issues/detail?id=3048 too?
related? not quite. However by fixing it we at least hide the problem.
Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown.
It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock.
Stef
with the MCMethodDefinition>>shutdown hack it work well
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No argument there. You might have had better weak collections to work with, but hopefully things like Cog and Sig's finalization improvements will give us similar advantages. Either way, it is important to have good session start/stop awareness and to sever ties at the right time (and to not do so at the wrong times). ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda@gmail.com] Sent: Saturday, October 09, 2010 5:24 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Sat, Oct 9, 2010 at 2:05 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Sig, Ignore this if you see fit; it might not apply, but don't dismiss it too quickly - it will apply somewhere, somehow. First, are these things happening on shutdown, or on image save? I ask because while they seem to be getting straightened out over time, those concepts have long been intermingled to disadvantage that appears to be greatly underestimated. The correct solution to many startup/shtudown cleanup takes some adjustment. Image save is nothing - ignore it. Shutdown can almost be ignored, though it is wise and polite to try to clean up external resources, and we should have good tools for developers wanting/needing to do so in their own programs. A good OS will clean up resources when something quits, but Andreas and others would point out that there might not be an OS, or it might have been written in the north western US :) The real house cleaning magic happens on startup - all the stuff you bravely ignored on save is now, finally, junk and needs to be discarded. By following this approach, an image save is no big deal, the system does the best it can to clean up after itself on shutdown, and things that were retained post-save (because the image needs to be able to plod along as though nothing happened) get chopped out early in startup and lazily recreated when appropriate. But remember it is far more efficient in start-up time to use a weak collection of objects that need to be junked/voided/finalized than an allInstancesDo: or two. I made VisualWorks start up about 4 times quicker by e.g. keeping font instances in a collection for voiding their handles on start-up. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua@gmail.com<mailto:siguctua@gmail.com>] Sent: Saturday, October 09, 2010 11:38 AM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] 12186 image quit problem On 9 October 2010 09:02, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote:
Igor
Is it also related to http://code.google.com/p/pharo/issues/detail?id=3048 too?
related? not quite. However by fixing it we at least hide the problem. Somehow , removing weakdependent during shutdown leads to semaphore deadlock. But i don't think that it exactly because MCMethodDefinition registers weakdependent. It could be any other thing, which registers weakdependent and then tries to remove it from weakdependents during shutdown. It also quite hard to reproduce. I was able to lock image few times using script , which Pavel provided. But then running same image with same VM again, didn't lead to lock.
Stef
with the MCMethodDefinition>>shutdown hack it work well
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Eliot Miranda -
Igor Stasenko -
Levente Uzonyi -
Schwab,Wilhelm K -
Stéphane Ducasse