does UseParallelOldGC guarantee a better full gc performance
the.6th.month at gmail.com
the.6th.month at gmail.com
Fri Apr 20 08:01:39 PDT 2012
Hi, Srinivas:
Can you explain more about "since in general the incidence of the deferred
updates phase may be affected by the number and size of the deferred
objects and their oop-richness". I don't quite understand what it means and
if it doesn't bother you too much, can you possible give some explanations
about what a deferred object means.
Thanks a million.
All the best,
Leon
On 20 April 2012 17:44, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
> BTW, max compaction doesn't happen every time, i think it happens in the
> 4th gc and then every 20th gc or so.
> It;s those occasional gc's that would be impacted. (And that had been our
> experience with generally good performance
> but the occasional much slower pause. Don't know if your experience is
> similar.)
>
> No I don't think excessive deadwood is an issue. What is an issue is how
> well this keeps up,
> since in general the incidence of the deferred updates phase may be
> affected by the number and
> size of the deferred objects and their oop-richness, so I am not sure how
> good a mitigant
> avoiding maximal compaction is for long-lived JVM's with churn of latge
> objects in the old
> gen.
>
> -- ramki
>
>
> On Thu, Apr 19, 2012 at 1:51 AM, the.6th.month at gmail.com <
> the.6th.month at gmail.com> wrote:
>
>> hi, Srinivas:
>> that explains, i do observe that no performance gain has been obtained
>> thru par old gc via the jmx mark_sweep_time (i have a monitoring system
>> collecting that and print out with rrdtool). hopefully that's the result of
>> maximum compaction, but i am keen to ask whether it will bring about any
>> negative impact on performance, like leaving lots of fragmentations
>> unreclaimed.
>>
>> all th best
>> Leon
>> On Apr 19, 2012 4:07 AM, "Srinivas Ramakrishna" <ysr1729 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 18, 2012 at 10:36 AM, Jon Masamitsu <
>>> jon.masamitsu at oracle.com> wrote:
>>>
>>>> Leon,
>>>>
>>>> I don't think I've actually seen logs with the same flags except
>>>> changing
>>>> parallel old for serial old so hard for me to say. Simon's comment
>>>>
>>>> > Well, maybe. But it shows that the parallel collector does its work,
>>>> > since you had a 41.91/13.06 = 3.2x gain on your 4 cores.
>>>>
>>>
>>> I think Simon's "speed up" is a bit misleading. He shows that the
>>> wall-time of 13.06 s
>>> does user time eqvt work worth 41.91 seconds, so indeed a lot of
>>> user-level work is
>>> done in those 13.06 seconds. I'd call that "intrinsic parallelism"
>>> rather than speed-up.
>>> However, that's a misleading way to define speed-up because
>>> (for all that the user cares about) all of that parallel work may be
>>> overhead of the parallel algorithm
>>> so that the bottom-line speed-up disappears. Rather, Simon and Leon, you
>>> want to compare
>>> the wall-clock pause-time seen with parallel old with that seen with
>>> serial old (which i believe
>>> is what Leon may have been referring to) which is how speed-up should be
>>> defined when
>>> comparing a parallel algorithm with a serial couterpart.
>>>
>>> Leon, in the past we observed (and you will likely find some discussion
>>> in the archives) that
>>> a particular phase called the "deferred updates" phase was taking a bulk
>>> of the time
>>> when we encountered longer pauses with parallel old. That's phase when
>>> work is done
>>> single-threaded and would exhibit lower parallelism. Typically, but not
>>> always, this
>>> would happen during the full gc pauses during which maximal compaction
>>> was forced.
>>> (This is done by default during the first and every 20 subsequent full
>>> collections -- or so.)
>>> We worked around that by turning off maximal compaction and letting the
>>> dense prefix
>>> alone.
>>>
>>> I believe a bug may have been filed following that discussion and it had
>>> been my intention to
>>> try and fix it (per discussion on the list). Unfortunately, other
>>> matters intervened and I was
>>> unable to get back to that work.
>>>
>>> PrintParallelGC{Task,Phase}Times (i think) will give you more visibility
>>> into the various phases etc. and
>>> might help you diagnose the performance issue.
>>>
>>> -- ramki
>>>
>>>
>>>> says there is a parallel speed up, however, so I'll let you investigate
>>>> you application
>>>> and leave it at that.
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 4/18/2012 9:27 AM, the.6th.month at gmail.com wrote:
>>>> > Hi, Jon,
>>>> > yup,,,I know, but what is weird is the paroldgen doesn't bring about
>>>> better
>>>> > full gc performance as seen from JMX metrics but bring unexpected swap
>>>> > consumption.
>>>> > I am gonna look into my application instead for some inspiration.
>>>> >
>>>> > Leon
>>>> >
>>>> > On 19 April 2012 00:19, Jon Masamitsu<jon.masamitsu at oracle.com>
>>>> wrote:
>>>> >
>>>> >> **
>>>> >> Leon,
>>>> >>
>>>> >> In this log you see as part of an entry "PSOldGen:" which says you're
>>>> >> using the serial mark sweep. I see in your later posts that
>>>> "ParOldGen:"
>>>> >> appears in your log and that is the parallel mark sweep collector.
>>>> >>
>>>> >> Jon
>>>> >>
>>>> >>
>>>> >> On 4/18/2012 1:58 AM, the.6th.month at gmail.com wrote:
>>>> >>
>>>> >> Hi, Simon:
>>>> >>
>>>> >> this is the full gc log for your concern.
>>>> >> 2012-04-18T16:47:24.824+0800: 988.392: [GC
>>>> >> Desired survivor size 14876672 bytes, new threshold 1 (max 15)
>>>> >> [PSYoungGen: 236288K->8126K(247616K)] 4054802K->3830711K(4081472K),
>>>> >> 0.0512250 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]
>>>> >>
>>>> >> 2012-04-18T16:47:24.875+0800: 988.443: [Full GC [PSYoungGen:
>>>> >> 8126K->0K(247616K)] [PSOldGen: 3822585K->1751429K(3833856K)]
>>>> >> 3830711K->1751429K(4081472K) [PSPermGen: 81721K->81721K(262144K)],
>>>> >> 6.6108630 secs] [Times: user=6.62 sys=0.00, real=6.61 secs]
>>>> >>
>>>> >> the full gc time is almost unchanged since I enabled paralleloldgc.
>>>> >>
>>>> >> Do you have any recommendation for an appropriate young gen size?
>>>> >>
>>>> >> Thanks
>>>> >>
>>>> >> All the best,
>>>> >> Leon
>>>> >>
>>>> >>
>>>> >> On 18 April 2012 16:24, Simone Bordet<sbordet at intalio.com> <
>>>> sbordet at intalio.com> wrote:
>>>> >>
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> On Wed, Apr 18, 2012 at 10:16, the.6th.month at gmail.com<
>>>> the.6th.month at gmail.com> <the.6th.month at gmail.com> wrote:
>>>> >>
>>>> >> hi all:
>>>> >> I'm currently using jdk 6u26. I just enabled UseParallelOldGC,
>>>> expecting
>>>> >> that would enhance the full gc efficiency and decrease the mark-sweep
>>>> >>
>>>> >> time
>>>> >>
>>>> >> by using multiple-core. The JAVA_OPTS is as below:
>>>> >> -XX:+PrintGCDetails -XX:+PrintGCDateStamps
>>>> -XX:+PrintTenuringDistribution
>>>> >> -Xloggc:gc.log-server -Xms4000m -Xmx4000m -Xss256k -Xmn256m
>>>> >> -XX:PermSize=256m -XX:+UseParallelOldGC -server
>>>> >> -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
>>>> >> as shown in jinfo output, the settings have taken effect, and the
>>>> >> ParallelGCThreads is 4 since the jvm is running on a four-core
>>>> server.
>>>> >> But what's strange is that the mark-sweep time remains almost
>>>> unchanged
>>>> >>
>>>> >> (at
>>>> >>
>>>> >> around 6-8 seconds), do I miss something here? Does anyone have
>>>> the same
>>>> >> experience or any idea about the reason behind?
>>>> >> Thanks very much for help
>>>> >>
>>>> >> The young generation is fairly small for a 4GiB heap.
>>>> >>
>>>> >> Can we see the lines you mention from the logs ?
>>>> >>
>>>> >> Simon
>>>> >> --http://cometd.orghttp://intalio.comhttp://bordet.blogspot.com
>>>> >> ----
>>>> >> Finally, no matter how good the architecture and design are,
>>>> >> to deliver bug-free software with optimal performance and
>>>> reliability,
>>>> >> the implementation technique must be flawless. Victoria Livschitz
>>>> >> _______________________________________________
>>>> >> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://
>>>> mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://
>>>> mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> hotspot-gc-use mailing list
>>>> >> hotspot-gc-use at openjdk.java.net
>>>> >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>> >>
>>>> >>
>>>> _______________________________________________
>>>> hotspot-gc-use mailing list
>>>> hotspot-gc-use at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120420/6cbe0357/attachment-0001.html
More information about the hotspot-gc-use
mailing list