does UseParallelOldGC guarantee a better full gc performance

Wed Apr 18 13:07:19 PDT 2012

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/20120418/7ed96c7a/attachment.html 