Revert "Update jemalloc to 4.5.0"

This reverts commit 65d0be3b7b540145c22409b1a79f7d263422e19b.

2 files changed, 23 insertions, 1 deletions

diff --git a/src/jemalloc b/src/jemalloc
-Subproject 3288e0659c08fb5006f6d6dd4b5675ed0c2c432
+Subproject 11bfb0dcf85f7aa92abd30524bb1e42e18d108c
diff --git a/src/liballoc_jemalloc/build.rs b/src/liballoc_jemalloc/build.rs
index 859e414a6fe..f3a0eebe698 100644
--- a/src/liballoc_jemalloc/build.rs
+++ b/src/liballoc_jemalloc/build.rs
@@ -93,7 +93,29 @@ fn main() {
        .env("AR", &ar)
        .env("RANLIB", format!("{} s", ar.display()));
 
-    if target.contains("ios") {
+    if target.contains("windows") {
+        // A bit of history here, this used to be --enable-lazy-lock added in
+        // #14006 which was filed with jemalloc in jemalloc/jemalloc#83 which
+        // was also reported to MinGW:
+        //
+        //  http://sourceforge.net/p/mingw-w64/bugs/395/
+        //
+        // When updating jemalloc to 4.0, however, it was found that binaries
+        // would exit with the status code STATUS_RESOURCE_NOT_OWNED indicating
+        // that a thread was unlocking a mutex it never locked. Disabling this
+        // "lazy lock" option seems to fix the issue, but it was enabled by
+        // default for MinGW targets in 13473c7 for jemalloc.
+        //
+        // As a result of all that, force disabling lazy lock on Windows, and
+        // after reading some code it at least *appears* that the initialization
+        // of mutexes is otherwise ok in jemalloc, so shouldn't cause problems
+        // hopefully...
+        //
+        // tl;dr: make windows behave like other platforms by disabling lazy
+        //        locking, but requires passing an option due to a historical
+        //        default with jemalloc.
+        cmd.arg("--disable-lazy-lock");
+    } else if target.contains("ios") {
         cmd.arg("--disable-tls");
     } else if target.contains("android") {
         // We force android to have prefixed symbols because apparently