Is ^{:once true} still necessary for lazy-seqs?

Skip to first unread message


Feb 18, 2014, 12:39:06 PM2/18/14
lazy-seq marks it's supplied lambdata with ^{:once true} to prevent the memory leak described at the bottom of this page.
However, while going over the code for clojure.lang.LazySeq, I noticed that ever since this commit by Rich, LazySeq doesn't extend AFn, but rather contains a reference to the lambda, fn, which it nullifies immediately after the first use, supposedly preventing any leaks caused by closed locals.
So my question is, is ^{:once true} still necessary for lazy-seqs, or does this (pretty old) change to LazySeq make it redundant?



Feb 18, 2014, 2:02:41 PM2/18/14
The same goes for delay (where the lambda reference is nullified), which leaves future-call, and even there :once is not really necessary.

A cursory benchmark indicated that lazy-seq does not, in fact, leak memory on long sequences, even without the :once flag. Am I missing anything?

BTW, the :once mechanism isn't (if I'm not mistaken) thread-safe. That's why LazySeq and Delay had to use synchronized blocks even when they relied on :once (again, if I'm correct in the assessment that they no longer do).

Alan Malloy

Feb 20, 2014, 8:12:03 PM2/20/14
^:once is absolutely needed for lazy seqs, because it allows the closed-over variables to get cleared while the lambda is still running, rather than waiting for it to finish. You can see the difference in this repl session:

user> (let [x (for [n (range)] (make-array Object 10000)), f (^:once fn* [] (nth x 1e6))] (f))
#<Object[] [Ljava.lang.Object;@402d3105>
user> (let [x (for [n (range)] (make-array Object 10000)), f (fn* [] (nth x 1e6))] (f))
; Evaluation aborted.

Of course you may need to tune the numbers to make sure it runs out of space on your machine, but the point is that without ^:once, the lambda f holds onto the head of x, in case f is called again. ^:once constitutes a promise to only ever call it once, and so the sequence is cleaned up as soon as possible. My example doesn't use LazySeq, but I hope you can see how the same considerations apply there.
Reply all
Reply to author
0 new messages