WeakArray problems (I think)

> OK - I've searched the archives and I think this is the "weakarray
> finalization" issue. Symptoms are that I start up the image and the UI
> locks with CPU stuck at 100%.
>
> I've tried:
> 1. Leaving it run for a few hours.
> 2. Starting the image with a script with
>    WeakArray runningFinalizationProcess terminate.
>
> Neither seems to get me past this point. I'd like to get to the stage of
> being able to browse+file out some classes if nothing else - there is a
> couple of days code there that I'd rather not lose.
>
> The top few lines in the process-listing (I had it open while
> investigating this before it reached this stage) are:
>
> (80) 3400: the timer interrupt watcher
> (60) 3351: the event tickler
> (60)  287: the user interrupt watcher
> (60) 1102: the low space watcher
> (50) 2355: the WeakArray finalization process
> (40) 4054: the UI process
> then a bunch of Semaphore>>critical and seaside connections all at (30).
>
> I'm not sure how accurate this is as I can't get the process browser to
> update before the UI locks.
>
> Anyone got any smart ideas?
>
> --
>   Richard Huxton
>   Archonet Ltd
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi,
>
> I expirienced similar problems with CPU eating at 100% (UNIX top command
> output)
> Image did not respond to socket requests at all. I sow it on FreeBSD quite
> frequently and on Linux time to time. I decided that it might happen
> becouse
> image takes all memory I left it to have with -memory switch to squeak
> command.
> To stop it I run a daily Seaside clean up (I think the same as per link
> 'Clear caches'
> on /seaside/config page). Hope that helps me, but not sure as it is only
> a week with this feature.
>
> I run squeak as follows:
> squeak -nodisplay -nosound -notimer -memory 512m esol.image

> Dmitry Dorofeev wrote:
>> Hi,
>> I expirienced similar problems with CPU eating at 100% (UNIX top  
>> command output)
>> Image did not respond to socket requests at all. I sow it on  
>> FreeBSD quite
>> frequently and on Linux time to time. I decided that it might  
>> happen becouse
>> image takes all memory I left it to have with -memory switch to  
>> squeak command.
>> To stop it I run a daily Seaside clean up (I think the same as per  
>> link 'Clear caches'
>> on /seaside/config page). Hope that helps me, but not sure as it  
>> is only a week with this feature.
>> I run squeak as follows:
>> squeak -nodisplay -nosound -notimer -memory 512m esol.image
>
> Thanks Dmitry!
>
> Defining a memory setting seems to do it. That'll buy me enough  
> time to ensure my code changes are safe - I can rebuild a fresh  
> image then.
>
>> without memory limit it is not stable at all (seems a problem  
>> above 1Gb)
>
> Useful pointer.
>
> Thanks very much.
>
> --
>   Richard Huxton
>   Archonet Ltd
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Adrian Lienhard wrote:
>> Is this an known problem of the VM? I couldn't find  a bug report  
>> on Mantis for this, so it would be good if you could add one with  
>> some more information (VM version, OS).
>
> The UI freezing is afaict just due to the fact that the garbage-
> collection via WeakArray etc is inefficient. Seaside uses weak  
> references quite a bit and my development image probably used them  
> a great deal (lots of new sessions started to test new code). Try  
> googling for "WeakArray finalization".--
>   Richard Huxton
>   Archonet Ltd
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside