does UseParallelOldGC guarantee a better full gc performance
the.6th.month at gmail.com
the.6th.month at gmail.com
Wed Apr 18 03:07:05 PDT 2012
Hi, Simon:
Thanks for your reply. That's really weird, I'll look into it and give the
feedback later
Thanks again.
All the best,
Leon
On 18 April 2012 17:19, Simone Bordet <sbordet at intalio.com> wrote:
> Hi,
>
> On Wed, Apr 18, 2012 at 10:58, the.6th.month at gmail.com
> <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?
>
> Usually, applications generate a lot of short lived objects that can
> be reclaimed very efficiently in the young generation.
> If you have a small young generation, these objects will be promoted
> in old generation, where their collection is usually more expensive.
>
> It really depends what your application does, but I would remove the
> -Xmn option for now (leaving the default of 1/3 of the total heap,
> i.e. ~1.6 GiB), and see if you get benefits.
>
> As for the times being unchanged, I do not know.
> My experience is that UseParallelOldGC works as expected: I frequently
> see 1.5-2x gains on 2 cores, and I have seen 6x gains on 8 cores.
>
> Simon
> --
> http://cometd.org
> http://intalio.com
> http://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 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/58299b7d/attachment.html
More information about the hotspot-gc-use
mailing list