Gerhard Froehlich wrote:
> Hi,
> <sigh> this stuff is so demotivating :-/.
I feel your pain.
>>Pooling objects will cause them to live longer than necessary. The
>>garbage collection methods will be much more efficient if you let it
>>do the memory management. We strongly advise taking out object pools.
>>
>>[ Editorial note: Component pooling and connection pooling have real
>> measured performance gains. These are due to the fact that they are
>> expensive to create. The comment is more for simple objects that are
>> pooled. ]
>>
>
> Ok but we pool our objects to increase our generating performance. I think
> that's a good deal, or?
The editorial notes are mine. We have measured performance gains due to the
fact that our Components are heavy to instantiate. The Pooled object argument
is only valid for small objects like String or Object where the initialization
is quick, and the teardown is quick.
>>Don't call System.gc(), HotSpot will make the determination of when its
>>appropriate and will generally do a much better job. If you are having
>>problems with the pause times for garbage collection or it taking too long,
>>then see the pause time question above.
>>
>>[ Editorial note: There is an option to disable explicit garbage collecting
>> calls to test this statement. (-XX:-DisableExplicitGC) ]
Did you test the system with this option enabled to see if we get any performance
increase?
>>Warming up loops for HotSpot is not necessary. HotSpot now contains On
>>Stack Replacement technology which will compile a running (interpreted)
>>method and replace it while it is still running in a loop. No need to
>>waste your application's time warming up seemingly infinite (or very long
>>running) loops in order to get better application performance.
>>
>>[ Editorial note: This does not apply to benchmarking. Do warm up the
>> VM by running your benchmark for a period of time before collecting
>> results. ]
>>
>
> Hmm more stuff to think about! Is this only Hotspot. How when people use
> the classic JVM? I have long discussion in the jakarta-commons group. Some
> people say, that the JVM GC is doing a good job and it would be better to
> let him work.
With JDK versions 1.3 and later, they are all HotSpot VMs. Even IBM's JVM
exibits much of the same functionality. I have a feeling that the number
of people using classic VMs will evaporate to nothing. This is especially
true when people want to squeeze performance out of their apps--and the
newer VMs do provide more flexibility in making those optimizations.
> In the meantime I have the same opinion. You can't really control the JVM.
> I try this now over a very long period and somehow I don't get to a really
> success. Maybe it would be better throw out this StoreJanitor stuff and Co.
> and only do the LRU and MRU stuff. Or we leave the StoreJanitor, but don't
> call the GC anymore!
Let's take out the explicit calls to GC--but keep actively maintaining cache
coherency. It would be interesting to see how it compares.
> It's no problem for me. I'm not married with that stuff and don't wanna hinder
> the success of Cocoon.
Glad to hear it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
