Default performance on Sun T5440

Tue Oct 6 21:27:11 UTC 2009

Jeff,

It's a little faster.

This is a Sun T5440, 4 1.4Ghz Niagara2(T2+) CPUs

I'm guessing that there is something about your
application that is hitting a weak spot in the collector.
If you can share the benchmark, that would help.

In the past we've seen performance problems with very
large objects, but there isn't any problem that we're
aware of in the latest jdk6 release.

Jon

On 10/06/09 14:02, jeff.lloyd at algorithmics.com wrote:
> Hi Jon,
> 
> Sorry for the delay - I took a long weekend.
> 
> Is it possible you are testing on a faster box than me?  Here is mine:
> 
> The sparcv9 processor operates at 1164 MHz,
>         and has a sparcv9 floating point processor.
> 
> Jeff
> 
> -----Original Message-----
> From: hotspot-gc-use-bounces at openjdk.java.net
> [mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Jon
> Masamitsu
> Sent: Friday, October 02, 2009 4:33 PM
> To: Jeff Lloyd
> Cc: hotspot-gc-use at openjdk.java.net
> Subject: Re: Default performance on Sun T5440
> 
> Jeff,
> 
> This is what I see running one of our benchmarks with a
> 1g heap on a T5440.
> 
> UseSerialGC
> 
> 81.908: [GC 81.908: [DefNew: 279616K->34943K(314560K), 1.6078835 secs]
> 464333K->241833K(1013632K), 1.6080676 secs] [Times: user=1.61 sys=0.00,
> real=1.61 secs]
> 
> UseParNewGC with default number of GC threads (85).  My appologies but I
> had
> the wrong fraction in my earlier mail.  Not 3/16 but 5/16.  Default
> number of GC
> threads is approximately number of strands * 5/16.
> 
> 49.001: [GC 49.001: [ParNew: 314558K->34942K(314560K), 0.1807405 secs]
> 601002K->350442K(1013632K), 0.1809190 secs] [Times: user=14.67 sys=0.02,
> real=0.18 secs]
> 
> UseParNewGC with 8 GC threads
> 
> 51.140: [GC 51.141: [ParNew: 279616K->34943K(314560K), 0.3261322 secs]
> 464428K->242091K(1013632K), 0.3262756 secs] [Times: user=2.60 sys=0.00,
> real=0.33 secs]
> 
> I arbitrarily took the last minor collection in each run.
> 
> Yes, between 85 GC threads and 8 GC threads we're doing lots more work
> (user time)
> for not that much gain in GC pause (less than a factor of two).   We're
> addressing that
> problem with CR 6593758 which will be smarter about the number of GC
> threads
> (use factors such as heap size and Java threads to figure out a better
> number of GC
> threads).
> 
> But I don't see the egregious increase in pause times that you're
> seeing.
> 
> 18.8885468 (default number of GC threads) secs vs. 0.1646787 (with 8 GC
> threads)
> 
> So something more is in play.
> 
> Jon
> 
> 
> Jon Masamitsu wrote On 10/02/09 12:28,:
> 
>> Jeff,
>>
>> When I can get access to a T5440 I'll do some experiments.
>> Do you have a benchmark you can give us?
>>
>> Jon
>>
>> jeff.lloyd at algorithmics.com wrote On 10/02/09 11:37,:
>>
>>  
>>
>>> Hi Jon,
>>>
>>> I'm using 1.6.0_16.  I can solve it by reducing the number of parallel
>>> threads for ParNew or using serial new collection - that's ok.  
>>>
>>> I just wanted to raise this as a usability issue because I'm a
> developer
>>> and this issue came to me from the field.  I'm concerned that few
> people
>>> in the field understand java/gc enough to fix or even recognize such
> an
>>> issue.  And this is the default jvm behaviour on the new multithreaded
>>> servers (though the default is pure parallel gc instead of cms OG -
>>> probably the same problem).
>>>
>>> So, I don't have a problem right now, but I may have more in the
> future
>>> because our app is supported on many platforms and now the default
>>> number of gc threads won't work well for clients running the Sun JVM
> on
>>> particular Sun servers.  Maybe 3/16 is too high?
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM] 
>>> Sent: Friday, October 02, 2009 2:14 PM
>>> To: Jeff Lloyd
>>> Cc: hotspot-gc-use at openjdk.java.net
>>> Subject: Re: Default performance on Sun T5440
>>>
>>> Jeff,
>>>
>>> This might be something different.  First what jdk are you using?
>>> What's you command line?  If you are using CMS, can you
>>> try a run with -XX:-UseParNewGC?  If not using CMS, can
>>> you try -XX:+UseSerialGC (assuming you're using jdk5 or
>>> later).
>>>
>>> Jon
>>>
>>> jeff.lloyd at algorithmics.com wrote On 10/02/09 10:56,:
>>>
>>>
>>>
>>>    
>>>
>>>> Hi John,
>>>>
>>>> Thanks for responding.  However I just want to show you a simple gc
>>>> without manually setting the number of gc cpus:
>>>>
>>>> 178.427: [GC 178.427: [ParNew: 471872K->52416K(471872K), 18.8885468
>>>> secs] 1054705K->756342K(12530496K), 18.8895357 secs] [Times:
>>>>   
>>>>
>>>>      
>>>>
>>> user=740.49
>>>
>>>
>>>    
>>>
>>>> sys=15.54, real=18.89 secs]
>>>>
>>>> Compared to a similar gc when I set the max parallel cpus to 8:
>>>>
>>>> 170.531: [GC 170.532: [ParNew: 118014K->13056K(118016K), 0.1646787
>>>>   
>>>>
>>>>      
>>>>
>>> secs]
>>>
>>>
>>>    
>>>
>>>> 863713K->771012K(12569856K), 0.1651373 secs] [Times: user=0.76
>>>>   
>>>>
>>>>      
>>>>
>>> sys=0.05,
>>>
>>>
>>>    
>>>
>>>> real=0.17 secs]
>>>>
>>>> I apologize it isn't totally apples-to-apples because I reduced the
> YG
>>>>   
>>>>
>>>>      
>>>>
>>> >from 512M to 128M, but look at the difference in "user" time.  After
>>>
>>>
>>>    
>>>
>>>> 5-10 minutes of uptime my application was reporting 135 minutes of
> cpu
>>>> time with the default settings.
>>>>
>>>> I'm not sure if this is helpful to you or the appropriate place to
>>>> provide feedback, but this is what people are going to be seeing if
>>>>   
>>>>
>>>>      
>>>>
>>> they
>>>
>>>
>>>    
>>>
>>>> don't understand gc details.
>>>>
>>>> Jeff
>>>>
>>>> -----Original Message-----
>>>> From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM] 
>>>> Sent: Friday, October 02, 2009 1:40 PM
>>>> To: Jon Masamitsu
>>>> Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net
>>>> Subject: Re: Default performance on Sun T5440
>>>>
>>>> Jon Masamitsu wrote On 10/02/09 10:19,:
>>>>
>>>>
>>>>
>>>>   
>>>>
>>>>      
>>>>
>>>>> Jeff,
>>>>>
>>>>> The default number of GC threads was changed to be fewer in
>>>>> jdk6u14 (same change in jdk7). I'm guessing you're using
>>>>> an older jdk? The number of GC threads depends on the
>>>>> number of cores on the platform. I think on the T5440 the
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>        
>>>>>
>>>> ^^^^^^^^^^^^  cores should be strands
>>>>
>>>>
>>>>
>>>>   
>>>>
>>>>      
>>>>
>>>>> number will be about 3/16 * 256 or 48.
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>     
>>>>>
>>>>>        
>>>>>
>>>> This is still correct.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
> --
>>>>   
>>>>
>>>>      
>>>>
>>> ---
>>>
>>>
>>>    
>>>
>>>> This email and any files transmitted with it are confidential and
>>>>   
>>>>
>>>>      
>>>>
>>> proprietary to Algorithmics Incorporated and its affiliates
>>> ("Algorithmics"). If received in error, use is prohibited. Please
>>> destroy, and notify sender. Sender does not waive confidentiality or
>>> privilege. Internet communications cannot be guaranteed to be timely,
>>> secure, error or virus-free. Algorithmics does not accept liability
> for
>>> any errors or omissions. Any commitment intended to bind Algorithmics
>>> must be reduced to writing and signed by an authorized signatory.
>>>
>>>
>>>    
>>>
>>>> ---------------------------------------------------------------------
> --
>>>>   
>>>>
>>>>      
>>>>
>>> ---
>>>
>>>
>>>    
>>>
>>>>   
>>>>
>>>>      
>>>>
>>> ----------------------------------------------------------------------
> ----
>>> This email and any files transmitted with it are confidential and
> proprietary to Algorithmics Incorporated and its affiliates
> ("Algorithmics"). If received in error, use is prohibited. Please
> destroy, and notify sender. Sender does not waive confidentiality or
> privilege. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. Algorithmics does not accept liability for
> any errors or omissions. Any commitment intended to bind Algorithmics
> must be reduced to writing and signed by an authorized signatory.
>>> ----------------------------------------------------------------------
> ----
>>>
>>>    
>>>
>> _______________________________________________
>> 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
> 
>  
> --------------------------------------------------------------------------
> This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
> --------------------------------------------------------------------------
> _______________________________________________
> 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