Fwd: Better default for ParallelGCThreads and ConcGCThreads by using number of physical cores and CPU mask.

[Jon Masamitsu]

David,

Thanks for taking a look at this.

On 11/24/2013 6:19 PM, David Holmes wrote:
> Hi Jon,
>
> On 23/11/2013 3:24 AM, Jon Masamitsu wrote:
>> This is a contribution regarding the number of GC worker threads to
>> use.  Part of the change queries /proc on linux to get the number of
>> active cores on the platform.  The changes are in
>>
>> http://cr.openjdk.java.net/~jmasa/8028554/webrev.00/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.frames.html 
>>
>>
>> Can someone familiar with this code take a look to see
>> if it is reasonable and done in a way that is consistent
>> with other /proc queries.
>
> I can't comment on that specifically but I do have reservations about 
> this proposed patch.
>
> First we have a general problem that "active processor count" doesn't 
> take into account the various resource management mechanisms that can 
> limit the actual "processors" available to the VM when it is running. 
> I would prefer to see that general problem solved. It also isn't clear 
> to me that the sched_getaffinity usage will correctly reflect the use 
> of tasksets/cpusets. (Note on solaris we try to handle some of these 
> mechanisms eg pbind and psrsets but still don't handle resource pools.)

Is there any work being done on the general problem?  I also would
like to see this solved.  I've always thought of it as runtime code that
GC uses.  Do you see it as a GC responsibility?

>
> Second, this feeds into future work on NUMA-awareness that will likely 
> need a more sophisticated set of API's.

Can you explain more?

>
> Third I dislike that this is only really addressing linux-x86 and 
> leaving the other platforms to default to cores==processors. That just 
> causes unnecessary divergence in platform functionality.

This is an interesting question with regard to open jdk contributions.
Yes, Oracle should do its best to implement on all platforms but
Google is a linux x86 shop and I personally don't expect them to implement
and performance test on all the supported platforms.   Should we be making
that a requirement for open jdk contributions?

>
> This is too late for JDK 8 and I think we will be doing more complete 
> work in this area during JDK 9 development.

Agreed that it is too late for jdk8.  I would think it would be suitable 
for an
8 update, however.  What is coming in jdk9 that affects this?

Jon

>
> Thanks,
> David
> -----
>
>> Thanks.
>>
>>
>> -------- Original Message --------
>> Subject:     Better default for ParallelGCThreads and ConcGCThreads by
>> using number of physical cores and CPU mask.
>> Date:     Tue, 19 Nov 2013 15:35:22 -0800
>> From:     Jungwoo Ha <jwha at google.com>
>> To:     hotspot-gc-dev at openjdk.java.net
>>
>>
>>
>> Hi,
>>
>> I am sending this webrev for the review.
>> (On behalf of Jon Masamitsu, it is upload here)
>> http://cr.openjdk.java.net/~jmasa/8028554/webrev.00/
>> <http://cr.openjdk.java.net/%7Ejmasa/8028554/webrev.00/>
>>
>> The feature is a new heuristics to calculate the default
>> ParallelGCThreads and ConGCThreads.
>> In x86, hyperthreading is generally bad for GC because of the cache
>> contention.
>> Hence, using all the hyper-threaded cores will slow down the overall GC
>> performance.
>> Current hotspot reads the number of processors that the Linux reports,
>> which treats all hyper-threaded cores equally.
>> Second problem is that when cpu mask is set, not all the cores are
>> available for the GC.
>>
>> The patch improves the heuristics by evaluating the actual available
>> physical cores
>> from the proc filesystem and the CPU mask, and use that as the basis for
>> calculating the ParallelGCThreads and ConcGCThreads.
>>
>> The improvements of GC pause time is significant. We evaluated on
>> Nehalem, Westmere, Sandybridge as well as several AMD processors. We
>> also evaluated on various CPU mask configuration and single/dual socket
>> configurations.
>> In almost all cases, there were speed up in GC pause time by 10~50%.
>>
>> We primarily use CMS collector for the evaluation, but we also tested on
>> other GCs as well.
>> Please take a look and let me know if this patch can be accepted.
>>
>> Thanks,
>> Jungwoo Ha
>>
>>
>>