Copied from: https://hg.mozilla.org/releases/mozilla-esr38/rev/4444e94a99cb
Security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2016-01/
Mozilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1221385

# HG changeset patch
# User Jan de Mooij <jdemooij@mozilla.com>
# Date 1451478429 -3600
# Node ID 4444e94a99cb9b00c0351cc8bf5459739cc036a5
# Parent  750e4cfc90f80df657e44c9c63b1865023d88682
Bug 1221385 - Handle OOM during JitRuntime initialization a bit better. r=bhackett a=abillings

diff --git a/js/src/jscompartment.cpp b/js/src/jscompartment.cpp
--- a/js/src/jscompartment.cpp
+++ b/js/src/jscompartment.cpp
@@ -138,28 +138,20 @@ JSRuntime::createJitRuntime(JSContext* c
 
     // 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;
 
     if (!jitRuntime_->initialize(cx)) {
-        js_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.
+        CrashAtUnhandlableOOM("OOM in createJitRuntime");
     }
 
     return jitRuntime_;
 }
 
 bool
 JSCompartment::ensureJitCompartmentExists(JSContext* cx)
 {