JDK-8187812 : UseMembar should be set true and deprecate the flag
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 10
  • Submitted: 2017-09-22
  • Updated: 2017-11-08
  • Resolved: 2017-11-08
Related Reports
CSR :  
Description
Summary
-------

Change default of -XX:+UseMembar from false to true and deprecate the flag.

Problem
-------

Hotspot currently has two mechanisms for forcing memory synchronization across threads. The default mechanism uses mprotect to force a pseudo-memory barrier, while the alternate (chosen by -XX:+UseMembar) uses a direct memory fence operation.

Using mprotect for IPI has several problems: 

 - It's not guaranteed to work on future hardware/OS:es (we could start using membarrier() with the MEMBARRIER_CMD_SHARED_EXPEDITED to be future proof (coming in 4.14)) 
 - It doesn't work on arm/arm64 (again MEMBARRIER_CMD_SHARED_EXPEDITED would solve this) 
 - Eventbased tracing must read thread states often (causes performance issues) 
 - The complexity in the code is costly 
 - The thread serialization is unstable on certain workloads/platforms/OS:es (last noticed this week on win x86) 
 - Fences are becoming cheaper
 - Thread-local handshakes are assumed to increase the reading of thread state
 - Scalability
 - JNI performance - false sharing

We want to move away from the mprotect mechanism.

Solution
--------

Set UseMembar to default to true and deprecate the flag. In the future we will obsolete the flag and only provide the membar mechanism.

Note that some applications can show performance regression. 
This is especially true for applications with few threads which do many short native calls.


Specification
-------------

Java HotSpot(TM) 64-Bit Server VM warning: Option UseMembar was deprecated in version 10.0 and will likely be removed in a future release.

    diff -r 6b8d7ed4fd9d src/cpu/ppc/vm/globals_ppc.hpp
    --- a/src/cpu/ppc/vm/globals_ppc.hpp	Mon Sep 25 17:22:56 2017 +0200
    +++ b/src/cpu/ppc/vm/globals_ppc.hpp	Tue Sep 26 12:21:17 2017 +0200
    @@ -72,1 +72,1 @@
    -define_pd_global(bool, UseMembar,             false);
    +define_pd_global(bool, UseMembar,             true);
    diff -r 6b8d7ed4fd9d src/cpu/s390/vm/globals_s390.hpp
    --- a/src/cpu/s390/vm/globals_s390.hpp	Mon Sep 25 17:22:56 2017 +0200
    +++ b/src/cpu/s390/vm/globals_s390.hpp	Tue Sep 26 12:21:17 2017 +0200
    @@ -74,1 +74,1 @@
    -define_pd_global(bool, UseMembar,            false);
    +define_pd_global(bool, UseMembar,            true);
    diff -r 6b8d7ed4fd9d src/cpu/sparc/vm/globals_sparc.hpp
    --- a/src/cpu/sparc/vm/globals_sparc.hpp	Mon Sep 25 17:22:56 2017 +0200
    +++ b/src/cpu/sparc/vm/globals_sparc.hpp	Tue Sep 26 12:21:17 2017 +0200
    @@ -77,1 +77,1 @@
    -define_pd_global(bool, UseMembar,            false);
    +define_pd_global(bool, UseMembar,            true);
    diff -r 6b8d7ed4fd9d src/cpu/x86/vm/globals_x86.hpp
    --- a/src/cpu/x86/vm/globals_x86.hpp	Mon Sep 25 17:22:56 2017 +0200
    +++ b/src/cpu/x86/vm/globals_x86.hpp	Tue Sep 26 12:21:17 2017 +0200
    @@ -87,1 +86,0 @@
    -#ifdef _ALLBSD_SOURCE
    @@ -89,3 +87,0 @@
    -#else
    -define_pd_global(bool, UseMembar,            false);
    -#endif
    diff -r 6b8d7ed4fd9d src/share/vm/runtime/arguments.cpp
    --- a/src/share/vm/runtime/arguments.cpp	Mon Sep 25 17:22:56 2017 +0200
    +++ b/src/share/vm/runtime/arguments.cpp	Tue Sep 26 12:21:17 2017 +0200
    @@ -384,0 +385,1 @@
    +  { "UseMembar",                    JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) },


Comments
Moving to approved.
08-11-2017

Yes, thanks, It should.
08-11-2017

Robbin: was this intended for the fast-track process? If so it should have been set to "Finalized" not "Proposed".
08-11-2017

I made some minor adjustments to the CSR - added an intro to tie the flag change with the IPI discussions, expanded solution and moved performance note there. Fixed a few grammatical issues. Marked as reviewed. This can be finalized for fast-tracking (or submitted for normal two stage process).
07-11-2017

You can find some good background information on this topic in Dave Dice's blogs: JNI performance - false sharing on the "-UseMembar" serialization page (Dave Dice) https://blogs.oracle.com/dave/jni-performance-false-sharing-on-the-usemembar-serialization-page QPI Quiescence (Dave Dice) https://blogs.oracle.com/dave/qpi-quiescence They both reference "Asymmetric Dekker Synchronization" by Dave Dice, Hui Huang and Mingyao Yang which unfortunately isn't available any more at the original location but can be retrieved thanks to the web archive at: http://web.archive.org/web/20080220051535/http://blogs.sun.com/dave/resource/Asymmetric-Dekker-Synchronization.txt
26-09-2017

The usual process would be to force to true and deprecate the flag in the next release, then obsolete it in the following one. (This is what is also proposed for AssumeMP.)
24-09-2017