What is Java's -XX:+UseMembar parameter

Question

I see this parameter in all kinds of places (forums, etc.) and the common answer it help highly concurrent servers. Still, I cannot find an official documentation from sun explaining what it does. Also, was it added in Java 6 or did it exist in Java 5?

(BTW, a good place for many hotspot VM parameters is this page)

Update: Java 5 does not boot with this parameter.

Answer 1

I don't agree with answer from butterchicken. This page http://www.md.pp.ru/~eu/jdk6options.html says that this flag causes memory barriers to be issued then thread changes it's state (from RUNNABLE to WAITING or to BLOCKED, for example).

Answer 2

In order to optimise performance, the JVM uses a "pseudo memory barrier" in code to act as a fencing instruction when synchronizing across multiple processors. It is possible to revert back to a "true" memory barrier instruction, but this can have a noticeable (and bad) effect upon performance.

The use of -XX:+UseMembar causes the VM to revert back to true memory barrier instructions. This parameter was originally intended to exist temporarily as a verification mechanism of the new pseudo-barrier logic, but it turned out that the new pseudo-memory barrier code introduced some synchronization issues. I believe these are now fixed, but until they were, the acceptable way to get around these issues was to use the reinstated flag.

The bug was introduced in 1.5, and I believe the flag exists in 1.5 and 1.6.

I've google-fu'ed this from a variety of mailing lists and JVM bugs:

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278
• The obligatory Wikipedia link to memory barriers (fencing instructions)
• A classic post from Raymond Chen
• SO question on fencing

Answer 3

butterchicken only explains half of the story, I would like to augment more detail to kmatveev's answer. Yes, the option is for thread state changes, and (pseudo) memory barriers are used to ensure that the change is visible from other threads, especially VM thread. Thread states used in OpenJDK6 are as follows:

//  _thread_new         : Just started, but not executed init. code yet (most likely still in OS init code)
//  _thread_in_native   : In native code. This is a safepoint region, since all oops will be in jobject handles
//  _thread_in_vm       : Executing in the vm
//  _thread_in_Java     : Executing either interpreted or compiled Java code (or could be in a stub)
...
 _thread_blocked           = 10, // blocked in vm   

Without UseMembar option, in Linux, Hotspot uses memory serialize page instead of memory barrier instruction. Whenever a thread state transition happens, the thread writes to a memory address in memory serialize page with volatile pointer. When the VM thread needs to look at up-to-date state of all the threads, VM changes the protection bits for the memory serialize page to read only and then recovers it to read/write to serialize state changes. More detailed mechanism is introduced in the following page:

http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt