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 "gc/shenandoah/shenandoahPadding.hpp"
  28 #include "memory/allocation.hpp"
  29 #include "utilities/globalDefinitions.hpp"
  30 
  31 /**
  32  * Provides safe handling of out-of-memory situations during evacuation.
  33  *
  34  * When a Java thread encounters out-of-memory while evacuating an object in a
  35  * load-reference-barrier (i.e. it cannot copy the object to to-space), it does not
  36  * necessarily follow we can return immediately from the LRB (and store to from-space).
  37  *
  38  * In very basic case, on such failure we may wait until the the evacuation is over,
  39  * and then resolve the forwarded copy, and to the store there. This is possible
  40  * because other threads might still have space in their GCLABs, and successfully
  41  * evacuate the object.
  42  *
  43  * But, there is a race due to non-atomic evac_in_progress transition. Consider
  44  * thread A is stuck waiting for the evacuation to be over -- it cannot leave with
  45  * from-space copy yet. Control thread drops evacuation_in_progress preparing for
  46  * next STW phase that has to recover from OOME. Thread B misses that update, and
  47  * successfully evacuates the object, does the write to to-copy. But, before
  48  * Thread B is able to install the fwdptr, thread A discovers evac_in_progress is
  49  * down, exits from here, reads the fwdptr, discovers old from-copy, and stores there.
  50  * Thread B then wakes up and installs to-copy. This breaks to-space invariant, and
  51  * silently corrupts the heap: we accepted two writes to separate copies of the object.
  52  *
  53  * The way it is solved here is to maintain a counter of threads inside the
  54  * 'evacuation path'. The 'evacuation path' is the part of evacuation that does the actual
  55  * allocation, copying and CASing of the copy object, and is protected by this
  56  * OOM-during-evac-handler. The handler allows multiple threads to enter and exit
  57  * evacuation path, but on OOME it requires all threads that experienced OOME to wait
  58  * for current threads to leave, and blocks other threads from entering.
  59  *
  60  * Detailed state change:
  61  *
  62  * Upon entry of the evac-path, entering thread will attempt to increase the counter,
  63  * using a CAS. Depending on the result of the CAS:
  64  * - success: carry on with evac
  65  * - failure:
  66  *   - if offending value is a valid counter, then try again
  67  *   - if offending value is OOM-during-evac special value: loop until
  68  *     counter drops to 0, then exit with resolving the ptr
  69  *
  70  * Upon exit, exiting thread will decrease the counter using atomic dec.
  71  *
  72  * Upon OOM-during-evac, any thread will attempt to CAS OOM-during-evac
  73  * special value into the counter. Depending on result:
  74  *   - success: busy-loop until counter drops to zero, then exit with resolve
  75  *   - failure:
  76  *     - offender is valid counter update: try again
  77  *     - offender is OOM-during-evac: busy loop until counter drops to
  78  *       zero, then exit with resolve
  79  */
  80 class ShenandoahEvacOOMHandler {
  81 private:
  82   static const jint OOM_MARKER_MASK;
  83 
  84   shenandoah_padding(0);
  85   volatile jint _threads_in_evac;
  86   shenandoah_padding(1);
  87 
  88   void wait_for_no_evac_threads();
  89 
  90 public:
  91   ShenandoahEvacOOMHandler();
  92 
  93   /**
  94    * Attempt to enter the protected evacuation path.
  95    *
  96    * When this returns true, it is safe to continue with normal evacuation.
  97    * When this method returns false, evacuation must not be entered, and caller
  98    * may safely continue with a simple resolve (if Java thread).
  99    */
 100   void enter_evacuation();
 101 
 102   /**
 103    * Leave evacuation path.
 104    */
 105   void leave_evacuation();
 106 
 107   /**
 108    * Signal out-of-memory during evacuation. It will prevent any other threads
 109    * from entering the evacuation path, then wait until all threads have left the
 110    * evacuation path, and then return. It is then safe to continue with a simple resolve.
 111    */
 112   void handle_out_of_memory_during_evacuation();
 113 
 114   void clear();
 115 };
 116 
 117 class ShenandoahEvacOOMScope : public StackObj {
 118 public:
 119   ShenandoahEvacOOMScope();
 120   ~ShenandoahEvacOOMScope();
 121 };
 122 
 123 #endif // SHARE_VM_GC_SHENANDOAH_SHENANDOAHEVACOOMHANDLER_HPP