Hmm, now I have a guilty conscience. In the cocoon1
project the gc() is forced in the free() method.
_sorry_ cocoon1ers for blaming you!
I think we can overtake the implementation.
But I have still doubts that memory is deallocated
immediately and that the memory calculation is
exact even if the gc() is forced after freeing
memory.
append a patch with the changes against the
2.1 branch.
Some side questions. Do I have to synchronize
the method in the store?
cheers
gerhard
>-----Ursprüngliche Nachricht-----
>Von: Gerhard Froehlich [mailto:[EMAIL PROTECTED]]
>Gesendet: Saturday, August 25, 2001 12:29 AM
>An: cocoon
>Betreff: [c2] MRUMemoryStore: can this really work?
>
>
>Hi,
>Because of Vadims entitled objections I just overlooked the cleanupthread
>in the MRUMemoryStore.
>When I developed this store I overtaken this thread from the MemoryStore
>of cocoon1 with the believe that it works.
>
>But thinking a little bit about it, I have my doubts that the while
>loop below works.
>The free() method removes the last element of the cache. But it's
>guaranteed that memory is immediately deallocated? The gc()is thread
>with minor priority and I have the apprehension that due this case
>this algorithm doesn't work right.
>
>What do you think out there?
><snip>
>if (this.jvm.totalMemory() - this.jvm.freeMemory() > this.heapsize) {
> this.jvm.runFinalization();
> this.jvm.gc();
> synchronized (this) {
> while ((this.cache.size() > 0) && (this.jvm.freeMemory() <
>this.freememory)) {
> this.free();
> }
> }
>}
></snip>
>
>Greets
>Gerhard
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>
patch.diff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
