You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/02/05 18:32:30 UTC
[Warning] StoreJanitor
I noticed something interesting from Java's Performance FAQ. It has
a number of VM tuning strategies that can be used by HotSpot 1.3+.
The faq (http://java.sun.com/docs/hotspot/PerformanceFAQ.html) has
an entry for pooling, calling System.gc(), etc.
QUESTION:
Should I pool objects to help GC? Should I call System.gc() periodically?
Should I warm up my loops first do that Hotspot will compile them?
ANSWER:
The answer to all these questions is No!
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. ]
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) ]
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. ]
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Warning] StoreJanitor
Posted by Gerhard Froehlich <g-...@gmx.de>.
Berin,
>> <sigh> this stuff is so demotivating :-/.
>
>I feel your pain.
Glad to here...
>>>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.
Yep.
>>>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?
Nope, but I have strong feeling it was more the opposite.
>>>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.
Ok.
>> 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.
I commented it out. Let's see how it works!
>> 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.
Otherwise it's the dead of each SW project.
~Gerhard
"EARTH FIRST! We'll strip-mine the other planets later."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Warning] StoreJanitor
Posted by Berin Loritsch <bl...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Warning] StoreJanitor
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
<sigh> this stuff is so demotivating :-/.
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>I noticed something interesting from Java's Performance FAQ. It has
>a number of VM tuning strategies that can be used by HotSpot 1.3+.
>
>The faq (http://java.sun.com/docs/hotspot/PerformanceFAQ.html) has
>an entry for pooling, calling System.gc(), etc.
>
>QUESTION:
>Should I pool objects to help GC? Should I call System.gc() periodically?
>Should I warm up my loops first do that Hotspot will compile them?
>
>ANSWER:
>
>The answer to all these questions is No!
>
>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?
>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) ]
>
>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.
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!
It's no problem for me. I'm not married with that stuff and don't wanna hinder
the success of Cocoon.
Thoughts?
~Gerhard
---------------------------------
Never share a foxhole with anyone
braver than you are.
---------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org