does UseParallelOldGC guarantee a better full gc performance

[the.6th.month at gmail.com]

hi, Simon:
here is another gc-log fragment about full gc, you can see that although
I've configured the jvm to UseParallelOldGC and increased the younggen size
to 768m, it still takes 13 seconds to finish the full gc, even worse than
before.

{Heap before GC invocations=109 (full 2):
 PSYoungGen      total 705984K, used 14531K [0x00000007d0000000,
0x0000000800000000, 0x0000000800000000)
  eden space 629120K, 0% used
[0x00000007d0000000,0x00000007d0000000,0x00000007f6660000)
  from space 76864K, 18% used
[0x00000007f6660000,0x00000007f7490da8,0x00000007fb170000)
  to   space 76672K, 0% used
[0x00000007fb520000,0x00000007fb520000,0x0000000800000000)
 ParOldGen       total 3309568K, used 3279215K [0x0000000706000000,
0x00000007d0000000, 0x00000007d0000000)
  object space 3309568K, 99% used
[0x0000000706000000,0x00000007ce25bd68,0x00000007d0000000)
 PSPermGen       total 262144K, used 79139K [0x00000006f6000000,
0x0000000706000000, 0x0000000706000000)
  object space 262144K, 30% used
[0x00000006f6000000,0x00000006fad48e38,0x0000000706000000)
2012-04-18T18:55:53.500+0800: 767.928: [Full GC [PSYoungGen:
14531K->0K(705984K)] [ParOldGen: 3279215K->1474447K(3309568K)]
3293746K->1474447K(4015552K) [PSPermGen: 79139K->74190K(262144K)],
13.0669910 secs] [Times: user=41.91 sys=0.19, real=13.06 secs]

quite counter-intuitive, huh?

Leon

On 18 April 2012 18:07, the.6th.month at gmail.com <the.6th.month at gmail.com>wrote:

> 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/37188e0a/attachment-0001.html