At 10:48 AM 8/28/2001 -0400, you wrote:
>Wow, where have you been before? :)))
>Yes, you are right - that's not necessary and this might be the
>performance issue.
>Reducing checker threads amount down to one would decrease amount of
>runFinalization()/gc()
>calls in two times - giving better performance.
>
>Could we use just one static checker thread?
>There is an issue with configuration though... Which configuration to use,
>from what store...
How about a separate component to do the checking? (MRUMemoryStoreJanitor?)
Each MRUMemoryStore would register its requested heapsize & freememory with
the janitor, and it would be responsible for the worker thread. It would
try to keep the JVM totalMemory below the sum of all the registered
heapsizes, and freeMemory below the sum of all registered freememories.
If runFinalization/gc isn't enough to create the free memory, a round-robin
approach (or other algorithm) could be used to select a MRUMemoryStore to
free an object from.
Some of the current MRUMemoryStore parameters would now be Janitor
parameters (namely cleanupthreadinterval and threadpriority).
Just my .02 :)
-pete
--
peter royal -> [EMAIL PROTECTED]
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
