JDK-8147910 : Cache initial active_processor_count
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-01-21
  • Updated: 2018-02-08
  • Resolved: 2016-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u121Fixed 9 b131Fixed openjdk7uFixed
Related Reports
Blocks :  
JDK-8161993 - G1 crashes if active_processor_count changes during startup
Relates :  
JDK-8149331 - Re-examine G1 use of os::processor_count
Relates :  
JDK-8166105 - Runtime.availableProcessors() ignores Linux taskset command
Relates :  
JDK-8179084 - HotSpot VM fails to start when AggressiveHeap is set
Relates :  
JDK-8147905 - Verify all uses of os::processor_count()
Description
The active_processor_count is the number of CPUs available to the JVM process and as such can change dynamically. For some uses it may be beneficial to cache the initial active processor count and use that value for decision making - eg for GC ergonomics.

The cached value could also be use by the os::print_cpu_info, and other routines, that want to report cpu information  but may be called in a crash context and so are limited in what they attempt to do. In particular they report the number of configured processors (processor_count()) not the number of available processors (active_processor_count()), because the former is an unchanging value cached at system initialization, while the latter requires system calls that make not be possible in a crash context.
Comments
Changed to bug as per David's suggestion. This is missing functionality.
22-07-2016
In os.cpp I would modify os::print_cpu_info as follows: void os::print_cpu_info(outputStream* st, char* buf, size_t buflen) { // cpu st->print("CPU:"); st->print("total %d", os::processor_count()); // It's not safe to query number of active processors after crash // st->print("(active %d)", os::active_processor_count()); + // but we can report the initial number of active processors + st->print(" (initial available %d)", os::initial_active_processor_count()); st->print(" %s", VM_Version::features_string()); st->cr(); pd_print_cpu_info(st, buf, buflen); } and I agree that I think it is safe to initialize initial_active_processor_count in os::init_before_ergo() - which is shared code.
22-07-2016
I would argue that adding this API should be considered a bug-fix now not an enhancement. When I filed this it seemed something potentially useful - a record of the initial number of available processors. But such an API is now required by the GC to fix JDK-8161993 - we need to size the GC based on the actual available number of processors (active_processor_count) but that value must then remain constant for use in other parts of the GC. While the GC could keep an internal cached value for its own use it makes more sense to use this proposed API.
22-07-2016
Prototype for this introducing an initial_active_processor_count() variable to fix crashes for changing os::processor_count() return values for G1. This has been made to kind of solve the in JDK-8149331 mentioned backed-out change. Not sure how this real issue ties into this. Additionally, this CR suggests further improvements. I could spend some little more work on this, but I do not exactly know where else you want this value to be used. Otherwise I suggest separating this issue and fixing the crashes.
01-04-2016
I think this simple enhancement should be considered for JDK 9.
08-02-2016