Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett
authorJan de Mooij <jdemooij@mozilla.com>
Wed, 30 Dec 2015 13:27:09 +0100
changeset 318100 350fbdbad784715d2e36a4dcb3eb7d89002033e2
parent 318099 fcd8d385410805aa3fadc7f027c478f65cda7dbc
child 318101 27b9d60e819cce5f20de8a0c48b1aa40522c7dd2
push id8842
push usergijskruitbosch@gmail.com
push dateThu, 31 Dec 2015 13:04:55 +0000
reviewersbhackett
bugs1221385
milestone46.0a1
Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett
js/src/jscompartment.cpp
--- a/js/src/jscompartment.cpp
+++ b/js/src/jscompartment.cpp
@@ -163,29 +163,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::AutoPreventBackedgePatching apbp(cx->runtime(), 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)
 {