[Seaside] WeakArray (again)

David Shaffer cdshaffer at acm.org
Fri Mar 24 21:22:10 UTC 2006


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



More information about the Seaside mailing list