cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: [Warning] StoreJanitor
Date Tue, 05 Feb 2002 20:38:55 GMT
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


Mime
View raw message