JDK-8152292 : Consider using proper OS APIs for os::serialize_thread_states
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-03-21
  • Updated: 2019-05-02
  • Resolved: 2018-11-09
Related Reports
Relates :  
Relates :  
Relates :  
Description
os::serialize_thread_states implements a pseudo memory barrier as part of the ADS synchronization mechanism for the thread safepoint states.
The implementation relies on side-effects of modifying the page protection bits in order to generate some sort of IPI in the OS kernel.
Both Windows and Linux now provide an explicit userspace API for triggering such an IPI.
On Windows the entry point is FlushProcessWriteBuffers()
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683148%28v=vs.85%29.aspx (Vista and up)

On Linux the syscall entry point is sys_membarrier is available from kernel version 4.3 but since the syscall may not be exposed by glibc it may be necessary to invoke the syscall directly, on x64 it's #324, more information at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
and at
http://man7.org/linux/man-pages/man2/membarrier.2.html
Comments
UseMembar is obsoleted, no longer possible to use anything other than fence.
09-11-2018

Note that normal sys_membarrier is slower than mprotect. In 4.14 the new MEMBARRIER_CMD_PRIVATE_EXPEDITED should preform the same.
07-11-2017

We should also re-examine use of os::serialize_thread_states versus UseMembar. See JDK-8143878.
08-02-2017