Other |
---|
tbdUnresolved |
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
The GC uses the processor count to calculate default values for ParallelGCThreads and ConcGCThreads, as well as in calculating adaptive values in AdaptiveSizePolicy::calc_active_workers(). Issues to consider: - Actual vs available CPUs running on a virtualized machine. This case is trivial - OS only reports CPUs available to virtualized machine. (Although HotSpot can see unusual configs, like 3 CPU machines). - Actual vs available CPUs running on a container (Solaris Zone). Solaris reports total CPUs , not available CPUs? - Actual vs available CPUs running on under tasksets. Linux reports total CPUs , not available CPUs? - Online processor count can change during execution. On some embedded system, it may change as cores are put to sleep? If so, should we limit GC to the awake CPUs? I think not - it's time to wake them up! Runtime APIs currently available: os::processor_count() os::active_processor_count() So the goal is to: 1) Determine the maximum number of processors GC will ever see at startup so it can size some data structures. 2) Determine the current number of processors GC should consider using in AdaptiveSizePolicy calculations.
|