Rose Tree Children Appear to be Eagerly Evaluated (Clojure 1.12+)

Mon, 31 Aug 2026 18:18:35 +0000

To make a long story shorter, I've been aggressively profiling the generative tests I rely on on a daily basis. In CI, they run on memory-constrained machines which have occasionally ended up in OOM states that cause our test executor to kill the nodes running some generative tests. In many cases, we've been able to adjust sizing to get under the line and resume normally. I've been running into that case more frequently, and have been looking for potential causes/levers to adjust in the source code.

The below findings are from my relatively powerful Macbook:

Operating System: MacOS (Tahoe - AArch64)
Clojure version: Verified on 1.12.1, Compared against 1.11.4
JDK vendor and version: OpenJDK 21.0.11

Using clj-async-profiler and an allocation/timing macro from Clojure Goes Fast, I benchmarked clojure.test.check.generators against some pretty common generators (Assume I'm using gen as an alias for that namespace):

gen/string
gen/large-integer
(gen/map gen/keyword gen/string)

While benchmarking, ReentrantLock (and ReentrantLock$NonfairSync), accounted for ~1/3rd of all allocations. Since Clojure 1.12, each LazySeq also allocates a ReentrantLock, so I reran the benchmarking after downgrading to Clojure 1.11.4 Obviously, all of those object references were no longer in the profiler results, but the amount of bytes allocated did consistently shrink (~10-15%, depending on the generator).

Most of the allocation appears to be happening while constructing the children segments of nodes in the rose tree. To my knowledge, we only ever lean on the full tree when shrinking results, and wouldn't read them on a generate-only pass. To test that, I wrapped the children arguments to a few of the make-rose calls in the call tree for string generation, and re-instrumented on v.12.1

This approximated the same reduction in memory use as downgrading to 1.11.4, and wiped out almost all of the ReentrantLock allocation events. I've been able to verify the fix does not break any tests, and that shrinking is functional as well.

For posterity / reproduction, the specific call sites I wrapped the children in were:

clojure.test.check.rose-tree
- join
- fmap
- shrink
- shrink-vector*
clojure.test.check.generators
- int-rose-tree

Happy to share the profiler output / git patch if anyone is interested!

Is the ant build broken in Clojure 1.12.1?

Tue, 03 Jun 2025 14:26:14 +0000

I have an old script that gets the Clojure source from github and calls ./antsetup.sh and then ant to build and test. With Clojure 1.12.1, it fails trying to compile the recently modified SwissArmy.java. My work-around was to modify the build.xml so that the java compiler would see the build directory on the classpath. (It's likely there's a better fix. I'm no expert with ant.)

diff --git a/build.xml b/build.xml index 1464b69e..8ce4a961 100644
--- a/build.xml
+++ b/build.xml @@ -99,6 +99,7 @@
       unless="maven.test.skip">
 <mkdir dir="${test-classes}"/>
 <javac srcdir="${jtestsrc}" destdir="${test-classes}" includeJavaRuntime="yes"
classpath="${maven.test.classpath}:${build}"
        debug="true" source="1.8" target="1.8" includeantruntime="no"/>
 <echo>Direct linking = ${directlinking}</echo>
 <java classname="clojure.lang.Compile"

I think it's probably better to use mvn test in my script as I'm only making sure I can build Clojure from source. However, technically this looks like a regression and it may break some old automation. Perhaps, ant is more trouble than it's worth at this point. Up to you. I'm fine with dropping support. I just wanted to point out the issue so you were aware of it.

Clojure Q&A - Recent questions tagged 1.12.1 regression

Rose Tree Children Appear to be Eagerly Evaluated (Clojure 1.12+)

Is the ant build broken in Clojure 1.12.1?