JDK-8148771 : os::active_processor_count() returns garbage which causes VM to crash.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-02-01
  • Updated: 2020-09-01
  • Resolved: 2016-02-02
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 9
9 b107Fixed
Related Reports
Duplicate :  
JDK-8148756 - TestOptionsWithRanges.java gets SIGSEGV in G1FromCardCache::invalidate()
Relates :  
JDK-8147906 - G1 use of os::processor_count()
Description
This problem only occurs on the odroid-xu machines.

# Problematic frame:
# V  [libjvm.so+0x3f8764]  G1FromCardCache::clear(unsigned int)+0x23
#
Comments
I'm sorry to hear that the initial attempt to get GCs to use active_processor_count failed. I've been focused on "containers", where a large number of processors on a server is split up among different containers, each of which gets a constant number of processors during the lifetime of the container. But of course on mobile platforms it is very possible for the number of active processors to change during execution as part of power management. To handle this correctly, GCs must either be prepared for dynamic changes to active processors or if creating a static data structure at startup, only use one initial value of os_processor_count. There are additional considerations for mobile computing - power consumption is relatively more important, so using relatively fewer GC threads may be reasonable. OTOH, preventing UI stutters is also relatively more important ... software is hard.
16-02-2016
I will use this to backout the change from JDK-8147906. I suspect the problem is getting two different values for the active_processor_count during initialization. A better fix for that is to provide an initial_active_processor_count() API to use. Update: JBS only just showed me the previous comments. Seems we are all on the same page just to need to confirm who will do the backout.
02-02-2016
Per Thomas's comment, remove duplicates link from this bug to JDK-8148766 Test AvailableProcessors.java got wrong number of processors. Also change subcomponent back to GC.
01-02-2016
Garbage is a too strong word. It looks as if these ARM machines return different values of os::active_processor_count() depending on some unknown factors (power management - odroid-xu's are mobile chips after all, so I can imagine that after a sleep period complete processors are shut down, only to be woken up if there is a significant amount of work for some time). This may actually be a to-be-supported use case (is it?). The existing GC code is not prepared for that at all, and with JDK-8147906 it started to use os::active_processor_count() to initialize some static data structures. If later the active processor count changes (e.g. increases), that GC code will access some arrays out of bounds, getting NULL values. I think JDK-8147906 should be reverted for now. Support for a changing number of processors at runtime needs a lot more thought and changes throughout all parallel/concurrent GCs than only changing a few os::processor_count() calls to os::active_processor_count(). If that has been the goal of the change. Even just determining the number of available CPUs at startup and storing it in a global location, and using that value somewhere with all GCs would need a bit more changes and thinking through the code than the existing JDK-8147906 provides. If that is a usable short-term solution. JDK-8147905 actually does not seem to say what behavior is expected.
01-02-2016
Where does the "returns garbage" become evident?
01-02-2016