[Pharo-project] Finalization quirk
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas? Bill
"Schwab,Wilhelm" == Schwab,Wilhelm K <bschwab@anest.ufl.edu> writes:
Wilhelm> I am trying to add finalization to something and appear to be at a Wilhelm> point that finalization does not happen until I open the process Wilhelm> browser. Any ideas? You're already past the point where you realize that finalization happens "sometime in the future" right? As in, it won't happen until the VM happens to notice that nobody holds a reference to the object, typically during a garbage collection sweep. If you're not past that point, you soon will be. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Finalisation seems a bit random in Squeak/Pharo. Sometimes needs a globalGarbageCollect to kick it. Part of the reason we try to avoid excessive use (Sockets still remain etc.). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, January 06, 2010 6:12 PM Subject: [Pharo-project] Finalization quirk
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary, At this point, I'd settle for evidence that it is at least random. So far, it appears to do nothing until some type of "big" system event happens, almost to the point of acting like a pre-shutdown cleanup. I _thought_ I saw more predictable activity in another situation where I use finalization, but that might have been more that I was squeezing bugs out of my finalization code and was just happy to see the end of the walkbacks :) It could also be that the code in question is a little memory hungry and was (just a guess) kicking off more and more substantial GC activity and prodded finalization that way?? For laughs I tried switching the mutual exclusion semaphore to a mutex, and tried signaling the finalization semaphore myself. Neither seemed to improve the situation. In my current situation, finalization is really a coward's way out anyway. I have gnuplot giving me png images via pipes, and now want to begin to do that more than once per external process, and also to allow it to work if the goal is indeed to write files, etc. So far, I have been reading the image off the pipe and closing gnuplot more or less in one operation, which needs to change. With good coding, I should be able to retain ensured cleanup and still allow multiple interactions per OS process, and with fewer gnuplot instances created, some delay in finalizing them (if I do fail to ensure cleanup) should not be a big disaster. That said, I still think there is something wrong with the current finalization implementation. At best, it is nowhere near as predicatable as Dolphin's finlizer. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Wednesday, January 06, 2010 1:20 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization quirk Finalisation seems a bit random in Squeak/Pharo. Sometimes needs a globalGarbageCollect to kick it. Part of the reason we try to avoid excessive use (Sockets still remain etc.). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, January 06, 2010 6:12 PM Subject: [Pharo-project] Finalization quirk
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas?
Bill
_______________________________________________ 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
Bill, I always tell people (a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary You're violating (a) There is mention of doing a full GC will force the finalization, but I can't recall if that finalizes (all) objects in old oops space in one pass with squeak. Various Smalltalk flavours and versions do things differently, some at different times & versions perhaps would only finalize one oops per pass (visualage). On 2010-01-06, at 10:12 AM, Schwab,Wilhelm K wrote:
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John, I realize you are being helpful and appreciate same. However, I am not violating anything; I am simply noting that Pharo is probably not finalizing objects nearly as soon as it could. My expectations (and awareness that it is not always immediate) come from Dolphin. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Wednesday, January 06, 2010 3:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization quirk Bill, I always tell people (a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary You're violating (a) There is mention of doing a full GC will force the finalization, but I can't recall if that finalizes (all) objects in old oops space in one pass with squeak. Various Smalltalk flavours and versions do things differently, some at different times & versions perhaps would only finalize one oops per pass (visualage). On 2010-01-06, at 10:12 AM, Schwab,Wilhelm K wrote:
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC. SystemDictionary>>setGCParameters Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1. Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost of deferring some finalized objects.... Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide someone picked more rational numbers but I think it's time that we clean those up this whole area. Doing this won't solve your finalization timing problem, in fact it might make it even longer or never since the objective would be to avoid a full GC, and deal with the occasional "pig in the snake" issue. I've not looked but Squeak images might not invoke setGCBiasToGrowGCLimit: so they would be more prone to invoking a full GC. For WikiServer on the iPhone I fiddled with a custom memory policy that attempts to avoid a full GC as long as possible since a full GC pass is measured on an ipod touch in nearly thousands of milliseconds. On 2010-01-06, at 12:45 PM, Schwab,Wilhelm K wrote:
John,
I realize you are being helpful and appreciate same. However, I am not violating anything; I am simply noting that Pharo is probably not finalizing objects nearly as soon as it could. My expectations (and awareness that it is not always immediate) come from Dolphin.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Wednesday, January 06, 2010 3:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization quirk
Bill, I always tell people
(a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary
You're violating (a)
There is mention of doing a full GC will force the finalization, but I can't recall if that finalizes (all) objects in old oops space in one pass with squeak. Various Smalltalk flavours and versions do things differently, some at different times & versions perhaps would only finalize one oops per pass (visualage).
On 2010-01-06, at 10:12 AM, Schwab,Wilhelm K wrote:
I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Jan 6, 2010, at 22:09 , John M McIntosh wrote:
Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC.
SystemDictionary>>setGCParameters
Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1.
Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost of deferring some finalized objects....
Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide someone picked more rational numbers but I think it's time that we clean those up this whole area.
Where can I find #initializeMemorySettingsProfileSeaSide? Could you propose new parameters for these settings? It's time to adjust them for the new decade ;) Cheers, Adrian [...]
+1 On Jan 7, 2010, at 11:12 AM, Adrian Lienhard wrote:
On Jan 6, 2010, at 22:09 , John M McIntosh wrote:
Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC.
SystemDictionary>>setGCParameters
Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1.
Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost of deferring some finalized objects....
Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide someone picked more rational numbers but I think it's time that we clean those up this whole area.
Where can I find #initializeMemorySettingsProfileSeaSide? Could you propose new parameters for these settings? It's time to adjust them for the new decade ;)
Cheers, Adrian
[...]
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
initializeMemorySettingsProfileSeaSide
is in the pharo image also initializeMemorySettingsProfileQF which I have no idea about... On 2010-01-07, at 2:12 AM, Adrian Lienhard wrote:
On Jan 6, 2010, at 22:09 , John M McIntosh wrote:
Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC.
SystemDictionary>>setGCParameters
Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1.
Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost of deferring some finalized objects....
Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide someone picked more rational numbers but I think it's time that we clean those up this whole area.
Where can I find #initializeMemorySettingsProfileSeaSide? Could you propose new parameters for these settings? It's time to adjust them for the new decade ;)
Cheers, Adrian
[...]
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
ah, I see. I looked in PharoCore and hence didn't find it. These are from Damien's www.squeaksource.com/ImageForDevelopers.html We should integrate one default policy into PharoCore. What would be a sensible default? Cheers, Adrian On Jan 8, 2010, at 01:10 , John M McIntosh wrote:
initializeMemorySettingsProfileSeaSide
is in the pharo image also initializeMemorySettingsProfileQF which I have no idea about...
On 2010-01-07, at 2:12 AM, Adrian Lienhard wrote:
On Jan 6, 2010, at 22:09 , John M McIntosh wrote:
Oh sure Bill you're violating rule (a). In squeak a full finalization pass is require to finalize all objects. This runs in to the Pharo's desire to only do incremental GCs and avoid a full GC.
SystemDictionary>>setGCParameters
Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. Smalltalk setGCBiasToGrow: 1.
Which means that the image is happy to lurch around with a 16MB working space. Once that is exceeded then a full GC will occur. (yes yes, it's more complex that that, but it's just easier to say that's kinda what happens). The trade is deferring a full GC at the cost of deferring some finalized objects....
Frankly the default values for vmParameterAt: 5,6,24,25 I think are quite fictional based on desktop/laptop machines used in this decade, those values come from the era of 16Mhz 68030 macintosh SE/30 machines. However I do see that in initializeMemorySettingsProfileSeaSide someone picked more rational numbers but I think it's time that we clean those up this whole area.
Where can I find #initializeMemorySettingsProfileSeaSide? Could you propose new parameters for these settings? It's time to adjust them for the new decade ;)
Cheers, Adrian
[...]
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
On 2010-01-08, at 2:28 AM, Adrian Lienhard wrote:
ah, I see. I looked in PharoCore and hence didn't find it. These are from Damien's www.squeaksource.com/ImageForDevelopers.html
We should integrate one default policy into PharoCore. What would be a sensible default?
Cheers, Adrian
I'm currently looking into what the default values should be -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
excellent Stef On Jan 9, 2010, at 1:24 AM, John M McIntosh wrote:
On 2010-01-08, at 2:28 AM, Adrian Lienhard wrote:
ah, I see. I looked in PharoCore and hence didn't find it. These are from Damien's www.squeaksource.com/ImageForDevelopers.html
We should integrate one default policy into PharoCore. What would be a sensible default?
Cheers, Adrian
I'm currently looking into what the default values should be
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 06.01.2010 21:27, John M McIntosh wrote:
Bill, I always tell people
(a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary
(d) finalization will occur in a different process, right? Cheers Philippe
Yes, usually the finalization logic is a separate high priority process. I think in VisualAge you can also manually call a primitive to get more finalized objects as a way of hurrying finalization along. I have seen a case at a client where their "higher* priority task stalled finalization, but this was a mistake on their part by a novice, lowering the priority under memory management tasks fixed the problem. On 2010-01-10, at 2:45 AM, Philippe Marschall wrote:
On 06.01.2010 21:27, John M McIntosh wrote:
Bill, I always tell people
(a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary
(d) finalization will occur in a different process, right?
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
participants (7)
-
Adrian Lienhard -
Gary Chambers -
John M McIntosh -
merlyn＠stonehenge.com -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse