1 /*
   2  * Copyright (c) 2018, Red Hat, Inc. All rights reserved.
   3  *
   4  * This code is free software; you can redistribute it and/or modify it
   5  * under the terms of the GNU General Public License version 2 only, as
   6  * published by the Free Software Foundation.
   7  *
   8  * This code is distributed in the hope that it will be useful, but WITHOUT
   9  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  10  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  11  * version 2 for more details (a copy is included in the LICENSE file that
  12  * accompanied this code).
  13  *
  14  * You should have received a copy of the GNU General Public License version
  15  * 2 along with this work; if not, write to the Free Software Foundation,
  16  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  17  *
  18  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  19  * or visit www.oracle.com if you need additional information or have any
  20  * questions.
  21  *
  22  */
  23 
  24 #ifndef SHARE_VM_GC_SHENANDOAH_SHENANDOAHEVACOOMHANDLER_HPP
  25 #define SHARE_VM_GC_SHENANDOAH_SHENANDOAHEVACOOMHANDLER_HPP
  26 
  27 #include "memory/allocation.hpp"
  28 #include "utilities/globalDefinitions.hpp"
  29 
  30 /**
  31  * Provides safe handling of out-of-memory situations during evacuation.
  32  *
  33  * When a Java thread encounters out-of-memory while evacuating an object in a
  34  * write-barrier (i.e. it cannot copy the object to to-space), it does not necessarily
  35  * follow we can return immediately from the WB (and store to from-space).
  36  *
  37  * In very basic case, on such failure we may wait until the the evacuation is over,
  38  * and then resolve the forwarded copy, and to the store there. This is possible
  39  * because other threads might still have space in their GCLABs, and successfully
  40  * evacuate the object.
  41  *
  42  * But, there is a race due to non-atomic evac_in_progress transition. Consider
  43  * thread A is stuck waiting for the evacuation to be over -- it cannot leave with
  44  * from-space copy yet. Control thread drops evacuation_in_progress preparing for
  45  * next STW phase that has to recover from OOME. Thread B misses that update, and
  46  * successfully evacuates the object, does the write to to-copy. But, before
  47  * Thread B is able to install the fwdptr, thread A discovers evac_in_progress is
  48  * down, exits from here, reads the fwdptr, discovers old from-copy, and stores there.
  49  * Thread B then wakes up and installs to-copy. This breaks to-space invariant, and
  50  * silently corrupts the heap: we accepted two writes to separate copies of the object.
  51  *
  52  * The way it is solved here is to maintain a counter of threads inside the
  53  * 'evacuation path'. The 'evacuation path' is the part of evacuation that does the actual
  54  * allocation, copying and CASing of the copy object, and is protected by this
  55  * OOM-during-evac-handler. The handler allows multiple threads to enter and exit
  56  * evacuation path, but on OOME it requires all threads that experienced OOME to wait
  57  * for current threads to leave, and blocks other threads from entering.
  58  *
  59  * Detailed state change:
  60  *
  61  * Upon entry of the evac-path, entering thread will attempt to increase the counter,
  62  * using a CAS. Depending on the result of the CAS:
  63  * - success: carry on with evac
  64  * - failure:
  65  *   - if offending value is a valid counter, then try again
  66  *   - if offending value is OOM-during-evac special value: loop until
  67  *     counter drops to 0, then exit with read-barrier
  68  *
  69  * Upon exit, exiting thread will decrease the counter using atomic dec.
  70  *
  71  * Upon OOM-during-evac, any thread will attempt to CAS OOM-during-evac
  72  * special value into the counter. Depending on result:
  73  *   - success: busy-loop until counter drops to zero, then exit with RB
  74  *   - failure:
  75  *     - offender is valid counter update: try again
  76  *     - offender is OOM-during-evac: busy loop until counter drops to
  77  *       zero, then exit with RB
  78  */
  79 class ShenandoahEvacOOMHandler {
  80 private:
  81   static const jint OOM_MARKER_MASK;
  82 
  83   DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(volatile jint));
  84   volatile jint _threads_in_evac;
  85   DEFINE_PAD_MINUS_SIZE(1, DEFAULT_CACHE_LINE_SIZE, 0);
  86 
  87   void wait_for_no_evac_threads();
  88 
  89 public:
  90   ShenandoahEvacOOMHandler();
  91 
  92   /**
  93    * Attempt to enter the protected evacuation path.
  94    *
  95    * When this returns true, it is safe to continue with normal evacuation.
  96    * When this method returns false, evacuation must not be entered, and caller
  97    * may safely continue with a read-barrier (if Java thread).
  98    */
  99   void enter_evacuation();
 100 
 101   /**
 102    * Leave evacuation path.
 103    */
 104   void leave_evacuation();
 105 
 106   /**
 107    * Signal out-of-memory during evacuation. It will prevent any other threads
 108    * from entering the evacuation path, then wait until all threads have left the
 109    * evacuation path, and then return. It is then safe to continue with a read-barrier.
 110    */
 111   void handle_out_of_memory_during_evacuation();
 112 
 113   void clear();
 114 };
 115 
 116 class ShenandoahEvacOOMScope : public StackObj {
 117 public:
 118   ShenandoahEvacOOMScope();
 119   ~ShenandoahEvacOOMScope();
 120 };
 121 
 122 class ShenandoahEvacOOMScopeLeaver : public StackObj {
 123 public:
 124   ShenandoahEvacOOMScopeLeaver();
 125   ~ShenandoahEvacOOMScopeLeaver();
 126 };
 127 
 128 #endif // SHARE_VM_GC_SHENANDOAH_SHENANDOAHEVACOOMHANDLER_HPP