Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett a=abillings
authorJan de Mooij <jdemooij@mozilla.com>
Wed, 30 Dec 2015 13:27:09 +0100
changeset 310594 a6bb8cbba8cb97ff71afb2b728888761528163ae
parent 310593 804e88d73ce23c9313b7346b8fe303fb0237db32
child 310595 c02ba5b2cd2f3f2f9e58f1ff8d5944af3e0adb1c
push id5513
push userraliiev@mozilla.com
push dateMon, 25 Jan 2016 13:55:34 +0000
treeherdermozilla-beta@5ee97dd05b5c [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersbhackett, abillings
bugs1221385
milestone45.0a2
Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett a=abillings
js/src/jscompartment.cpp
--- a/js/src/jscompartment.cpp
+++ b/js/src/jscompartment.cpp
@@ -162,29 +162,22 @@ JSRuntime::createJitRuntime(JSContext* c
         return nullptr;
 
     // Protect jitRuntime_ from being observed (by InterruptRunningJitCode)
     // while it is being initialized. Unfortunately, initialization depends on
     // jitRuntime_ being non-null, so we can't just wait to assign jitRuntime_.
     JitRuntime::AutoMutateBackedges amb(jrt);
     jitRuntime_ = jrt;
 
+    AutoEnterOOMUnsafeRegion noOOM;
     if (!jitRuntime_->initialize(cx)) {
-        ReportOutOfMemory(cx);
-
-        js_delete(jitRuntime_);
-        jitRuntime_ = nullptr;
-
-        JSCompartment* comp = cx->runtime()->atomsCompartment();
-        if (comp->jitCompartment_) {
-            js_delete(comp->jitCompartment_);
-            comp->jitCompartment_ = nullptr;
-        }
-
-        return nullptr;
+        // Handling OOM here is complicated: if we delete jitRuntime_ now, we
+        // will destroy the ExecutableAllocator, even though there may still be
+        // JitCode instances holding references to ExecutablePools.
+        noOOM.crash("OOM in createJitRuntime");
     }
 
     return jitRuntime_;
 }
 
 bool
 JSCompartment::ensureJitCompartmentExists(JSContext* cx)
 {