WeakArray (again)

Hi all,

The WeakArray finalizationProcess is delaying seaside page delivery  
by a couple seconds. I know this problem pops up on this list every  
once and a while and the only "solution" I have seen is to use  
IdentityDictionary.

My problem is not that the WeakArray finalizationProces is taking  
over my image it just running at bad times. I noticed that it runs at  
userInterruptPriority. I am assuming that that is done to avoid some  
sort of race condition. Would it be safe for it to run at  
systemBackgroundPriority or userBackgroundPriority in an image that  
is only used for seaside ?

Would there be a way to run the finalizationProces at more controlled  
times like after the seaside request has been handled or even every  
so many minutes. Would doing something like the below be a bad idea  
(it would be forked to a lower process)

[true] whileTrue:[
        WeakArray runningFinalizationProcess terminate.
        (Delay forSeconds: 240) wait.
        WeakArray restartFinalizationProces.
].

I know the above might produce unexpected behavior in some  
applications but would it cause any problems?

The WeakArray issue is becoming a huge problem for us and I would  
love to see some sort of resolution to it.

Thanks
Will
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Squeak or VW ?
You did not say.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sorry Squeak.

The reason I am posting it to this list and Not the Squeak list is  
because I know other Seaside users experience this problem as well.

Thanks
Will
On Mar 24, 2006, at 11:01 AM, Bany, Michel wrote:

> Squeak or VW ?
> You did not say.
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Just a note: Restarting the image a clearing the caches solves the  
problem for a few hours so It could turn out the slow downs I am  
experiencing are not totally related to WeakArray.

 From the beginning I have experienced slow down issues on Squeak/
Seaside images running on Linux and while I have done a lot to reduce  
the problem it has not gone away. I am almost ready to give up and  
write some sort of load balancing script that expires/kills images  
after a few hours and after they are done handling active session.

It would be a terrible hack but I am getting far to many complaints  
about seaside applications slowing down and me having to save and  
restart the image.

Has anyone else experienced these issues and discovered a solution/
work around.

Thanks
Will
On Mar 24, 2006, at 10:40 AM, William Harford wrote:

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

William Harford wrote:

I wish there was a simple answer (well, there is a simple answer "fix
weak array finalization", but it doesn't seem likely to happen soon).
Here are some things I've done to avoid slowdown nightmares...they are
not all appropriate for all scenarios:

1) as you mentioned, remove the use of WeakIdentityKeyDictionary in
WAStateRegistry...this will mean you're sessions grow continually but is
OK for relatively short-lived sessions.
2) force session reclaimation on a periodic basis rather than checking
every ~10 requests (set up a service to call
WARegistry>>unregisterExpiredHandlers periodically and perform a
fullGC).  Unregistering sessions can be expensive and it happens on
average every time 10 new sessions are created.  This means that expired
sessions will hang around during periods of inactivity which are usually
the best times to reclaim them and GC.  I've found that simply checking
every few minutes improves the first page responsiveness of my largest
app.  I use a "Service" to do this (attached).
3) "register" a minimal amount of state...still each component uses a
"state holder" for each decoration (including the component itself).

Anyway...no rocket science here but I have a collection of applications
which sustain a fairly reasonable hit rate and I have not heard of (or
experienced myself) the "weak reclaimation freeze" since I took these
measures.  My users' sessions are relatively short so 1 and 2 have a big
impact.

David




'From Squeak3.7 of ''4 September 2004'' [latest update: #5989] on 9 April 2005 at 4:04:12 pm'!
ApplicationService subclass: #SessionExpirationService
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'SC-SeasideHacks'!

!SessionExpirationService methodsFor: 'private' stamp: 'cds 4/9/2005 16:04'!
informApplications
        WADispatcher default entryPoints do: [:app |
                app unregisterExpiredHandlers]! !


!SessionExpirationService methodsFor: 'running' stamp: 'cds 3/13/2005 19:04'!
runWhile: aBlock
        [aBlock value]
                whileTrue: [self informApplications.
                            Smalltalk garbageCollect.
                            self sleepFor: 30000]
! !

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Mar 24, 2006, at 1:23 PM, David Shaffer wrote:

>
> 1) as you mentioned, remove the use of WeakIdentityKeyDictionary in
> WAStateRegistry...this will mean you're sessions grow continually  
> but is
> OK for relatively short-lived sessions.

I can't do this. Our sessions are long lived and make numerous calls/
render. Doing this would quickly use up gobs of memory.


I have written similar code but have not tried it out in a production  
environment. I will give that a try.
Our sessions are long lived so I am not to sure how much a difference  
it will make but it can't hurt and it will clean up some DB  
connection sooner rather than later and that is a good thing.

> 3) "register" a minimal amount of state...still each component uses a
> "state holder" for each decoration (including the component itself).

The application uses call/render a lot. This was one of the main  
draws to using Seaside. It allows us to easily customize the  
application for our clients. We build our entire application out of  
smaller reusable components that can be easily customize/replaced.  
There are ~= 12 (and could go up to 30) components created for each  
request. In most cases the user moves on. Would limiting the number  
of pages a user can backtrack help the situation ?

Thanks
Will


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

William Harford wrote:

>
> The application uses call/render a lot. This was one of the main
> draws to using Seaside. It allows us to easily customize the
> application for our clients. We build our entire application out of
> smaller reusable components that can be easily customize/replaced.
> There are ~= 12 (and could go up to 30) components created for each
> request. In most cases the user moves on. Would limiting the number
> of pages a user can backtrack help the situation ?


I'm cross-posting to Squeak-dev and I think this should migrate to that
list (since it has come up there several times).  Please follow up to
Squeak-dev only.  I don't believe this is a problem for VisualWorks
which seems to have a significantly more robust weak reference mechanism.

...as for your question...

I don't have a good feeling for the impact of that.  It would limit the
size of the WALRUCache (?) used to track continuations but I'm not sure
that it would actually impact the lifetime of objects in the registry.
Actually I don't have much intuition at all regarding lifetime of the
objects in the registry.  I think the idea was that when a continuation
"expires" (gets pushed out of the LRU cache) then data in its "snapshot"
should be available for GC.  Keeping the cache small might limit the
number of items in the weak dictionary if you GC often enough.  Sorry I
can't say more.

Maybe Julian or Avi would care to chime in ;-)

\begin{amateurHour}

It seems to me that the notification needs to be changed to actually
queueing information about the objects which the GC deams
un(strongly)reachable.  I spent some time staring at
ObjectMemory>>sweepPhase, #finalizeReference: and #signalFinalization:
which seem to be the cornerstones of this process.  All that
#signalFinalization: is currently doing is signaling a semaphore (well,
indicating that one should be "signaled" later).  Why not keep a list of
(oop,i) [i is the offset of the weak reference in the oop] pairs and
somehow communicate those back to a Smalltalk object?  As a total VM
novice it just seems too simple ;-)  What I think I would do is
associate a queue like thing with every weak reference container.  Then
when an object becomes GC-able I'd place the (oop,i) pair in that shared
queue.  What I need is someone to hold my hand through...

...designing this "queue like thing".  How about a circular array which
can only be "read" (move the read index) by ST code and only be written
by the VM code?  This avoids a lot of concurrency issues.  Are there any
examples like this in the VM?

\end{amateurHour}

Andreas said it wasn't trivial and I believe him but I think we've got
to give it a try or risk having Squeak/Seaside being ignored for larger
projects.  It is also a big problem for anyone using GOODS or GLORP, for
example, since those libraries make extensive use of weak references.
So...is there anyone with a knowledge of the VM willing to step up,
design the solution and divvy up parts of it for those of us with a good
knowledge of C but little of the VM.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

 > So...is there anyone with a knowledge of the VM willing to step up,
 > design the solution and divvy up parts of it for those of us with a
 > good knowledge of C but little of the VM.

        A pox upon you if do this in handwritten C. :)

        (said the simulator enthusiast)


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside