JDK-8188764 : Obsolete AssumeMP and then remove all support for non-MP builds
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-04
  • Updated: 2021-09-06
  • Resolved: 2018-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 12
12 b14Fixed
Related Reports
Relates :  
JDK-8273380 - ARM32: Default to {ldrexd,strexd} in StubRoutines::atomic_{load|store}_long
Relates :  
JDK-8185062 - Set AssumeMP to true and deprecate the flag
Relates :  
JDK-8273378 - Shenandoah: Remove the remaining uses of os::is_MP
Relates :  
JDK-8204301 - Make OrderAccess functions available to hpp rather than inline.hpp files
Relates :  
JDK-8211046 - Forced data dependencies serve no purpose on x86
Description
We propose to only build for MP platforms. AssumeMP (which defaults to true since 18.3) is hardwired to true; os::is_MP is always true, and we can elide all code and code generation that provides for a non-MP path.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/84743156e780 User: dholmes Date: 2018-10-03 07:42:21 +0000
03-10-2018
Referring to John's items above I'm now thinking that we should address #1 by always assuming we have an MP system (modulo architectures that may not have the requisite instructions - though I don't think we currently have any of those). The other items should be examined case-by-case and still consult os::is_MP() is needed.
12-09-2018
Copied from JDK-8185062: John Rose added a comment - 2018-03-27 11:03 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".
12-09-2018
After further discussions it seems we should pursue this work.
12-09-2018
This work stalled due to the resurgence in use of single cpu/core "containers". It is unclear whether persuing this will adversely affect performance in those environments.
11-09-2018