--- a/src/hotspot/share/gc/z/zMessagePort.inline.hpp	Thu Jun 14 14:32:03 2018 +0200
+++ b/src/hotspot/share/gc/z/zMessagePort.inline.hpp	Fri Jun 15 13:31:20 2018 +0200
@@ -87,6 +87,17 @@
 
   // Wait for completion
   request.wait();
+
+  {
+    // Guard deletion of underlying semaphore. This is a workaround for a
+    // bug in sem_post() in glibc < 2.21, where it's not safe to destroy
+    // the semaphore immediately after returning from sem_wait(). The
+    // reason is that sem_post() can touch the semaphore after a waiting
+    // thread have returned from sem_wait(). To avoid this race we are
+    // forcing the waiting thread to acquire/release the lock held by the
+    // posting thread. https://sourceware.org/bugzilla/show_bug.cgi?id=12674
+    MonitorLockerEx ml(&_monitor, Monitor::_no_safepoint_check_flag);
+  }
 }
 
 template <typename T>

--- a/src/hotspot/share/gc/z/zPageAllocator.cpp	Thu Jun 14 14:32:03 2018 +0200
+++ b/src/hotspot/share/gc/z/zPageAllocator.cpp	Fri Jun 15 13:31:20 2018 +0200
@@ -337,6 +337,17 @@
       // Wait for allocation to complete or fail
       page = request.wait();
     } while (page == gc_marker);
+
+    {
+      // Guard deletion of underlying semaphore. This is a workaround for a
+      // bug in sem_post() in glibc < 2.21, where it's not safe to destroy
+      // the semaphore immediately after returning from sem_wait(). The
+      // reason is that sem_post() can touch the semaphore after a waiting
+      // thread have returned from sem_wait(). To avoid this race we are
+      // forcing the waiting thread to acquire/release the lock held by the
+      // posting thread. https://sourceware.org/bugzilla/show_bug.cgi?id=12674
+      ZLocker locker(&_lock);
+    }
   }
 
   return page;