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