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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>>>> "Schwab,Wilhelm" == Schwab,Wilhelm K <[hidden email]> 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
<[hidden email]> <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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 06, 2010 6:12 PM
Subject: [Pharo-project] Finalization quirk



_______________________________________________
Pharo-project mailing list
[hidden email]
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Indeed, not all per pass...

I find that, in Squeak, compared to VisualAge, for instance, that finalisation rarely happens regularly... This does tend to lead to quite prolonged processing when most critical...

----- Original message -----

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

> [hidden email]

> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--

===========================================================================

John M. McIntosh <[hidden email]>  Twitter:  squeaker68882

Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

===========================================================================

_______________________________________________

Pharo-project mailing list

[hidden email]

http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Chambers
Sent: Wednesday, January 06, 2010 1:20 PM
To: [hidden email]
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" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 06, 2010 6:12 PM
Subject: [Pharo-project] Finalization quirk



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

 
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: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh
Sent: Wednesday, January 06, 2010 3:28 PM
To: [hidden email]
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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 M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jan 6, 2010, at 22:09 , John M McIntosh wrote:

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

+1

On Jan 7, 2010, at 11:12 AM, Adrian Lienhard wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
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:

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

excellent

Stef
On Jan 9, 2010, at 1:24 AM, John M McIntosh wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project