JDK-8185062 : Set AssumeMP to true and deprecate the flag
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-07-21
  • Updated: 2019-05-22
  • Resolved: 2017-10-03
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 10
10 b31Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Description
Since is_MP() was introduced, the world has moved on in ways that makes its existence questionable.

First of all, most systems are indeed MP. Systems that return false are typically either very old or virtualized. Old systems we arguably do not care about so much, and as for virtualized systems it is a bug to assume is_MP can be set statically when initializing the VM.

Now the problem with virtualized environments that have become increasingly popular is that they are more dynamic. If you run Java in a docker container for example, it might be that the container starts with one CPU, only to have it bumped later on with docker update --cpus, dynamically giving the container more threads. However, since we already decided during initialization that is_MP could be set to false, synchronization code was elided, and the VM will crash.

Therefore, I propose that we turn is_MP on permanently, to prevent containers from crashing when dynamically resized. An alternative if we really want to insist on providing a non-MP runtime is to change AssumeMP to be true by default, and allow it to be explicitly turned off. I do not mind as long as the default setting is safety-first w.r.t. assuming the system is MP or not.
Comments
In the current code, is_MP is used for only a few purposes: 1. to gate the introduction of MP-specific features, notably memory barriers 2. to align certain patchable code sequences (method entry, call sites) 3. to gate certain optimizations which are questionable on uniprocessors (see quicken_jni_functions) 4. to gate optimizations which are desirable on uniprocessors (mutex/monitor short circuits) Item #1 is by far the most common, and is easily removed, since the memory barriers can be self-gating (expanding to no-ops on uniprocessors). The comment titled "is_MP Considered Redundant" in orderAccess.hpp reflects this point. For uses like this the is_MP can be removed without a trace. Regarding the other items, is_MP can be removed but it also serves a documentation purpose not always reflected in the comments. We should leave a comment behind saying why the action is taken (#2, #3), or to note the assumption that an MP is running the VM (#4). There are only a few places where item #4 occurs. They should leave a comment behind saying something that elaborates the current reasoning, something beginning like "if this were a UP, then we would not need to count backoff attempts here".
27-03-2018

This work will be done in two phases: 1. Under this bug, for 18.3, we will set AssumeMP to true by default and deprecate it. 2. Under a new issue, for 18.9 we will obsolete AssumeMP, and then remove all support for non-MP builds.
28-09-2017

I don't quite follow the alternative in the proposal. The way to "turn is_MP on permanently" would be to have AssumeMP default to true. That would be simple, safe and uncontroversial. A more radical proposal would be to elide os::is_MP and only build for MP systems. Then if anyone truly wants to run on a uniprocessor without paying any overhead they would have to build such a VM. If that were desirable then the way to handle that would be to have MP_ONLY/NOT_MP macros. If we no longer care about actively supporting such uniprocessor configurations then we always issue MP code. I'll start a discussion on hotspot-dev.
02-08-2017