[11] RFR 8249560: Shenandoah: Fix racy GC request handling

[Aleksey Shipilev]

Original fix:
  https://bugs.openjdk.java.net/browse/JDK-8249560
  https://hg.openjdk.java.net/jdk/jdk15/rev/0fbc72a46860

It does not apply cleanly to 11u, because MutexLockerEx is used in the middle of the hunk. I
reapplied it by hand:

diff -r 1584484e8128 src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       Thu Jul 23 12:46:24 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp       Mon Aug 10 09:37:04 2020 +0200
@@ -505,17 +505,19 @@
   // This is especially important for weak references cleanup and/or native
   // resources (e.g. DirectByteBuffers) machinery: when explicit GC request
   // comes very late in the already running cycle, it would miss lots of new
   // opportunities for cleanup that were made available before the caller
   // requested the GC.
-  size_t required_gc_id = get_gc_id() + 1;

   MonitorLockerEx ml(&_gc_waiters_lock);
-  while (get_gc_id() < required_gc_id) {
+  size_t current_gc_id = get_gc_id();
+  size_t required_gc_id = current_gc_id + 1;
+  while (current_gc_id < required_gc_id) {
     _gc_requested.set();
     _requested_gc_cause = cause;
     ml.wait();
+    current_gc_id = get_gc_id();
   }
 }

 void ShenandoahControlThread::handle_alloc_failure(ShenandoahAllocRequest& req) {
   ShenandoahHeap* heap = ShenandoahHeap::heap();


Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey