diff --git a/mk/rt.mk b/mk/rt.mk
index 8433b588e6b..9d12bf39825 100644
--- a/mk/rt.mk
+++ b/mk/rt.mk
@@ -128,12 +128,25 @@ define DEF_THIRD_PARTY_TARGETS
 
 # $(1) is the target triple
 
-ifeq ($$(CFG_WINDOWSY_$(1)), 1)
-  # This isn't necessarily a desired option, but it's harmless and works around
-  # what appears to be a mingw-w64 bug.
+ifeq ($$(CFG_WINDOWSY_$(1)),1)
+  # 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/
   #
-  # https://sourceforge.net/p/mingw-w64/bugs/395/
-  JEMALLOC_ARGS_$(1) := --enable-lazy-lock
+  # 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.
+  JEMALLOC_ARGS_$(1) := --disable-lazy-lock
 else ifeq ($(OSTYPE_$(1)), apple-ios)
   JEMALLOC_ARGS_$(1) := --disable-tls
 else ifeq ($(findstring android, $(OSTYPE_$(1))), android)
diff --git a/src/jemalloc b/src/jemalloc
index e24a1a025a1..f84e3092728 160000
--- a/src/jemalloc
+++ b/src/jemalloc
@@ -1 +1 @@
-Subproject commit e24a1a025a1f214e40eedafe3b9c7b1d69937922
+Subproject commit f84e30927284b0c500ed3eaf09e8e159da20ddaf