>> >Wow, where have you been before? :)))
Always there watching and learning much through this project and its
participants :). But most of the time in the dungeons of commercial
software development and its deadlines.
>> >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?
We have to test this. When static, we have namely one cleanup thread but
still two stores to free(). For the moment I don't know if this work.
But I have the strong feeling that it won't. Too bad that Carsten is
away for a couple of weeks. He would certainly have some good ideas for
the pipline configuration. But I will test this with a static thread.
>> >There is an issue with configuration though... Which
>configuration to use,
>> >from what store...
Maybe we can add a sample configuration to the cocoon.xconf according
to a reference config for the Xms Xmx parameters. Berin made some
good suggestions some threads below. I can add it to the cocoon.xconf.
>> 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
>
>Good suggestion and I kind of like this name ;)
>Gerhard, what do you think?
Good suggestion. But I would name it StoreJanitor. Because the
MRUMemoryStore
is *only* a component. Maybe there will be a LRUMemoryStore or combination
of
both in nearer future :). Every store component implements the store
interface, so
the StoreJanitor would have access to the free() method of every store
component.
Then we would have a seperate cleanup component for every store
implementation.
I would implement the stores as singelton classes with one instance for
better
control about the memory. Because, how do you decide from which store
instance
to free memory. Maybe there is one with many small objects and another with
less
but huge objects. You can't determine, like in C, the byte size of each
object in java easy.
>> try to keep the JVM totalMemory below the sum of all the registered
>> heapsizes, and freeMemory below the sum of all registered freememories.
>Here I think that idea (originally) was that heapsize specifies
>heapsize of the JVM,
>but not the size of the store (because it is (almost) impossible
>to determine), so my
>understanding is that these parameters (heapsize and freememory)
>should also
>go into janitor configuration.
Yeah, thats right. But I had the opinion that there is only one store
instance.
(I tested it too carelessly :( )
This gc()->jvm.FreeMemory()->gc()->jvm.FreeMemory() is the proposed
implementation (hack) from javasoft to determine memory consumption
of objects in java.
>> 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.
Yes, that would be a possible approach to decide from which store to free().
But
I still don't understand why 2 or more stores?
>> Just my .02 :)
Mine too :)
Cheers
Gerhard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
