Gerhard Froehlich wrote: > 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 >
Yes, 1/10 might be more effective in most cases. But remember there are typically 3 stores (I don't know why or whether this varies), so a krass half might be a not so krass 1/6 really! Remember it typically takes 2-3 seconds for each iteration if gc is called - so how long would it take to empty (or reduce by say 99%) if that is necessary? If you loose half of a store, will it be the least used half? If so it is probably a lot less used that the most used half - don't you think? So the effect on performance of loosing it might be only 10 percent or much less? Maybe the percent reduction on each iteration should be <dare I say it>a settable parameter</dare I say it>? Peter ------------------------ Two half-truths do not make a truth, and two half-cultures do not make a culture. Arthur Koestler (1905-83) Hungarian-born British writer. The Ghost in the Machine, Preface ------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
