<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>Clojure Q&amp;A - Recent questions tagged gc</title>
<link>https://ask.clojure.org/index.php/tag/gc</link>
<description></description>
<item>
<title>Replace core.async’s internal LinkedList queue with ArrayDeque?</title>
<link>https://ask.clojure.org/index.php/14696/replace-core-asyncs-internal-linkedlist-queue-arraydeque</link>
<description>&lt;p&gt;Hi! While reading the channel implementation I noticed the internal queue is a &lt;code&gt;java.util.LinkedList&lt;/code&gt;:&lt;br&gt;
&lt;a rel=&quot;nofollow&quot; href=&quot;https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj&quot;&gt;https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;The common JVM guidance these days is to prefer &lt;code&gt;java.util.ArrayDeque&lt;/code&gt; for FIFO/LIFO queues due to better locality and lower GC overhead. For example, the JDK docs state: “This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.”&lt;br&gt;
&lt;a rel=&quot;nofollow&quot; href=&quot;https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html&quot;&gt;https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html&lt;/a&gt;&lt;br&gt;
Related SO discussion: &lt;a rel=&quot;nofollow&quot; href=&quot;https://stackoverflow.com/questions/6163166/why-is-arraydeque-better-than-linkedlist&quot;&gt;https://stackoverflow.com/questions/6163166/why-is-arraydeque-better-than-linkedlist&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;A few questions for the maintainers:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Was &lt;code&gt;LinkedList&lt;/code&gt; originally chosen for a specific reason (e.g., very old JDK compatibility)?&lt;/li&gt;
&lt;li&gt;Are there behaviors in channels that specifically rely on &lt;code&gt;LinkedList&lt;/code&gt; (e.g., allowing null, I believe channels disallow nil anyway, or particular iterator characteristics), or would &lt;code&gt;ArrayDeque&lt;/code&gt; be a drop-in replacement for the add/remove-from-ends operations used?&lt;/li&gt;
&lt;li&gt;If we provide a small PR and benchmark showing an improvement (lower allocations / better throughput under contention), would such a change be considered?&lt;/li&gt;
&lt;li&gt;Since &lt;code&gt;ArrayDeque&lt;/code&gt; is available on Java 8+, and current Clojure/core.async baselines target that or newer, is there any remaining compatibility concern?&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Context: there was an older conversation in Clojurians (#clojure) that suggested ArrayDeque could reduce GC pressure under load and that the original choice may have been influenced by older JDKs:&lt;br&gt;
&lt;a rel=&quot;nofollow&quot; href=&quot;https://clojurians.slack.com/archives/C03S1KBA2/p1526551888000376&quot;&gt;https://clojurians.slack.com/archives/C03S1KBA2/p1526551888000376&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;If this sounds reasonable, I’m happy to run the core.async test suite, add JMH-style benchmarks focused on channel put/take hot paths, and submit a PR.&lt;/p&gt;
&lt;p&gt;Thanks!&lt;/p&gt;
</description>
<category>core.async</category>
<guid isPermaLink="true">https://ask.clojure.org/index.php/14696/replace-core-asyncs-internal-linkedlist-queue-arraydeque</guid>
<pubDate>Tue, 02 Sep 2025 08:02:18 +0000</pubDate>
</item>
</channel>
</rss>