Hi, yes, there arn't such things like boring sundays with Cocoon (TANSTLBSWC).
>From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > >> From: Peter Hargreaves [mailto:[EMAIL PROTECTED]] >> >> Hi Folks, >> >> Its great to see such enthusiasm - thanks for listening. Just got a >> coupe of comments and a simple idea that might help towards the >solution >> - if you scroll down. >> >> Gerhard Froehlich wrote: > ><snip/> > >> > Maybe I did something wrong. But the idea was that: >> > >> > while(MemoryIsLow) { >> > free objects out of the store //physicall >> > run gc >> > } >> > >> > I run the GC after each "free objects" to clean away >> > does not needed objects! >> > >> > The problem is now, that when he doesn't has anything >> > to free from the registered stores, he runs the GC >> > all the time. And then we have this endless loop! >> > >> > Therefore I should check if the Stores are empty. If they >> > are empty and there is nothing to free anymore we should >> > leave that loop. >> >> >> Is this where you mean: >> >> while (this.memoryLow() && this.getStoreList().size() > 0) { >> this.freeMemory(); >> } >> >> I assumed that "this.getStoreList().size()" returned 0 when all the >> stores were empty. If this is not the case (as you suggest) then it >> looks like a permanent loop. I have seen it come out of this loop >> however. Perhaps another thread freed up memory letting the gc become >> successful at breaking out of the loop through "this.memoryLow()". >> >> I saw it break out of the loop when I had the jvm -Xnoclassgc option >> set. With this option classes that haven't been used for a while get >> dropped from memory don't they? So, if stuck in a loop, it won't be >long >> before there are a lot of classes that haven't been used for a while! >> When I saw it come out, it was spectacular - a sudden big drop in >memory >> in use! >> >> >> > >> After that it waits as configured (threadinterval) >> > >> before the next execution. >> > >> >> > >> Maybe there is a more elegent solution. >> >> >> Hava you considered a sort of binary approach to emptying stores? >> >> while (MemoryIsLow) { >> free half of the items in the next store >> run gc >> } > >I guess half would be too radical :) >May be something like 1/10th (decimal approach) would do the job better? Everything no problem *if* the Store interface would have a method like <code>int size()</code>. But it doesn't provide this in the moment. And we all no how people react, when we change a work interface. But I can change the implementation of <code>Enumeration keys()</code> and determine so the size elements in the store. That would be possible. 1/10 I like. Half is a little bit <german>krass</german>. Think about that chain picture Stefano drawed. Gerhard -------------------------------------------- Very funny, Scotty. Now beam down my clothes. --------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
