does UseParallelOldGC guarantee a better full gc performance

Thu Apr 19 01:51:54 PDT 2012

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/20120419/f51227da/attachment-0001.html 