A micro-library for Clojure that provides versions of pmap and future that have first class support for virtual threads on JVMs that support them, and which transparently falls back on Clojure core pmap and future when virtual threads are not supported. These features are opt-in; this library does not monkey patch core Clojure or mess with the thread pools etc. that it sets up. It has no dependencies, other than on Clojure and any supported JVM, and is less than 100 lines of code.
Note that Clojure versions prior to 1.12 use synchronized blocks in the language and core library, which will reduce performance on JVMs < v24, since that construct pins virtual threads to platform threads (see JEP-444 and search for the first occurrence of the word "synchronized" for details, and see also JEP-491). Despite this, performance for I/O bound workloads that leverage virtual threads can be substantially better than the same workload running on platform threads, even on older Clojure and/or JVM versions.
srasu/spindle does this, albeit by monkey patching core.async. Rumour has it that Clojure v1.13 updates core.async to support virtual threads too.
What if I want per virtual thread state, using ScopedValues?
Check out multiplyco/scoped. It should pair nicely with embroidery, and has similar graceful degradation behaviour on older JVMs.
embroidery is available as a Maven artifact from Clojars.
API documentation is available here, or here on cljdoc, and the unit tests are also worth perusing to see worked examples.
$ clj -Sdeps '{:deps {com.github.pmonks/embroidery {:mvn/version "RELEASE"}}}'$ lein try com.github.pmonks/embroidery$ deps-try com.github.pmonks/embroideryLet's use Thread/sleep as a reasonable facsimile of a blocking I/O workload.
The script:
(require '[embroidery.api :as e])
(defn simulate-blocking-workloads [n] (doall (e/pmap* (fn [_] (Thread/sleep 1000)) (range n))))
(def cores (.availableProcessors (Runtime/getRuntime)))
;; First we run as many parallel jobs as there are CPU cores, just as a baseline
(let [f (future (time (simulate-blocking-workloads cores)))]
(Thread/sleep 250)
(println "Platform threads:" (count (Thread/getAllStackTraces)))
@f
nil)
;; Then we run way more parallel jobs than there are CPU cores
(let [f (future (time (simulate-blocking-workloads (* 1000 cores))))]
(Thread/sleep 250)
(println "Platform threads:" (count (Thread/getAllStackTraces)))
@f
nil)Representative results on a JVM that supports virtual threads (note that the exact results will vary somewhat from run to run and machine to machine):
;; Baseline job count
Platform threads: 11
"Elapsed time: 1005.569084 msecs"
nil
;; High job count
Platform threads: 22
"Elapsed time: 1027.093 msecs"
nilRepresentative results on a JVM that doesn't support virtual threads (where embroidery falls back on using vanilla clojure.core/pmap):
;; Baseline job count
Platform threads: 20
"Elapsed time: 1009.354875 msecs"
nil
;; High job count
Platform threads: 38
"Elapsed time: 440221.9605 msecs"
nilWhile it could be argued that this is merely highlighting a limitation of clojure.core/pmap (i.e. its fixed size thread pool and "chunking" approach), the reality is that there are good reasons for it to be implemented that way, and the alternatives on JVMs without virtual threads (i.e. spinning up several thousand platform threads for this workload) have substantial downsides and likely still won't perform as well as virtual threads do.
For example, if we replace simulate-blocking-workloads with this naive implementation:
(defn simulate-blocking-workloads
[n]
(let [threads (map #(Thread. (fn [] (Thread/sleep 1000)) (str "test-thread-" %)) (range n))]
(run! #(.start %) threads)
(run! #(.join %) threads)))The output becomes (on my machine - results will vary by run and machine):
;; High job count
Platform threads: 4214
[562.278s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 2048k, guardsize: 16k, detached.
[562.278s][warning][os,thread] Failed to start the native thread for java.lang.Thread "test-thread-9183"
Execution error (OutOfMemoryError) at java.lang.Thread/start0 (Thread.java:-2).
unable to create native thread: possibly out of memory or process/resource limits reachedThis project uses the git-flow branching strategy, and the permanent branches are called release and dev. Any changes to the release branch are considered a release and auto-deployed (JARs to Clojars, API docs to GitHub Pages, etc.).
For this reason, all development must occur either in branch dev, or (preferably) in temporary branches off of dev. All PRs from forked repos must also be submitted against dev; the release branch is only updated from dev via PRs created by the core development team. All other changes submitted to release will be rejected.
embroidery uses tools.build. You can get a list of available tasks by running:
clojure -A:deps -T:build help/doc
Of particular interest are:
clojure -T:build test- run the unit testsclojure -T:build lint- run the linters (clj-kondo and eastwood)clojure -T:build ci- run the full CI suite (check for outdated dependencies, run the unit tests, run the linters)clojure -T:build install- build the JAR and install it locally (e.g. so you can test it with downstream code)
Please note that the release and deploy tasks are restricted to the core development team (and will not function if you run them yourself).
Copyright © 2023 Peter Monks
Distributed under the Mozilla Public License, version 2.0.
SPDX-License-Identifier: MPL-2.0