diff --git a/include/heyoka/llvm_state.hpp b/include/heyoka/llvm_state.hpp
index 4ee929cbf..a6fb77d52 100644
--- a/include/heyoka/llvm_state.hpp
+++ b/include/heyoka/llvm_state.hpp
@@ -348,17 +348,18 @@ std::optional<llvm_mc_value> llvm_state_mem_cache_lookup(const std::vector<std::
 void llvm_state_mem_cache_try_insert(std::vector<std::string>, unsigned, llvm_mc_value);
 
 // The default setting for the parjit flag for llvm_multi_state.
-// There is evidence of an LLVM thread scheduling bug when parallel compilation
-// is active, that rarely results in multiply-defined symbols for external C
-// functions, which leads to compilation failure. So far, we have been able to
-// trigger this issue only on 64-bit arm.
-inline constexpr bool default_parjit =
-#if defined(HEYOKA_ARCH_ARM)
-    false
-#else
-    true
-#endif
-    ;
+//
+// At this time, it seems like parallel compilation in lljit is buggy:
+//
+// - on Unix platforms, parallel compilation occasionally results in
+//   multiply-defined symbols for external C functions, which leads to
+//   compilation failures;
+// - on Windows, it seems like parallel compilation outright results in
+//   segmentation faults under heavy load.
+//
+// The root of the problem seems to be a concurrency issue. Thus, for the time
+// being, let us just disable parallel compilation by default.
+inline constexpr bool default_parjit = false;
 
 } // namespace detail
 
diff --git a/src/llvm_state.cpp b/src/llvm_state.cpp
index 52f71cc56..af5fc6d6d 100644
--- a/src/llvm_state.cpp
+++ b/src/llvm_state.cpp
@@ -1667,11 +1667,17 @@ multi_jit::multi_jit(unsigned n_modules, unsigned opt_level, code_model c_model,
 
 #else
 
+    // NOTE: never enable parallel compilation on Windows due to
+    // segfaults under heavy load.
+#if !defined(_WIN32)
+
     if (m_parjit) {
         // Set the number of compilation threads.
         lljit_builder.setNumCompileThreads(std::thread::hardware_concurrency());
     }
 
+#endif
+
 #endif
 
     // Create the jit.