60 // of the max heap size. Otherwise fall back to using a single shared small |
60 // of the max heap size. Otherwise fall back to using a single shared small |
61 // page. This is useful when using small heaps on large machines. |
61 // page. This is useful when using small heaps on large machines. |
62 const size_t per_cpu_share = (MaxHeapSize * 0.03125) / ZCPU::count(); |
62 const size_t per_cpu_share = (MaxHeapSize * 0.03125) / ZCPU::count(); |
63 return per_cpu_share >= ZPageSizeSmall; |
63 return per_cpu_share >= ZPageSizeSmall; |
64 } |
64 } |
|
65 |
|
66 static uint nworkers_based_on_ncpus(double cpu_share_in_percent) { |
|
67 return ceil(os::initial_active_processor_count() * cpu_share_in_percent / 100.0); |
|
68 } |
|
69 |
|
70 static uint nworkers_based_on_heap_size(double reserve_share_in_percent) { |
|
71 const int nworkers = (MaxHeapSize * (reserve_share_in_percent / 100.0)) / ZPageSizeSmall; |
|
72 return MAX2(nworkers, 1); |
|
73 } |
|
74 |
|
75 static uint nworkers(double cpu_share_in_percent) { |
|
76 // Cap number of workers so that we don't use more than 2% of the max heap |
|
77 // for the small page reserve. This is useful when using small heaps on |
|
78 // large machines. |
|
79 return MIN2(nworkers_based_on_ncpus(cpu_share_in_percent), |
|
80 nworkers_based_on_heap_size(2.0)); |
|
81 } |
|
82 |
|
83 uint ZHeuristics::nparallel_workers() { |
|
84 // Use 60% of the CPUs, rounded up. We would like to use as many threads as |
|
85 // possible to increase parallelism. However, using a thread count that is |
|
86 // close to the number of processors tends to lead to over-provisioning and |
|
87 // scheduling latency issues. Using 60% of the active processors appears to |
|
88 // be a fairly good balance. |
|
89 return nworkers(60.0); |
|
90 } |
|
91 |
|
92 uint ZHeuristics::nconcurrent_workers() { |
|
93 // Use 12.5% of the CPUs, rounded up. The number of concurrent threads we |
|
94 // would like to use heavily depends on the type of workload we are running. |
|
95 // Using too many threads will have a negative impact on the application |
|
96 // throughput, while using too few threads will prolong the GC-cycle and |
|
97 // we then risk being out-run by the application. Using 12.5% of the active |
|
98 // processors appears to be a fairly good balance. |
|
99 return nworkers(12.5); |
|
100 } |