I think the condition here means that the loop compilation can't tell that the s local is definitely out of scope and can be cleared, so you end up holding the head.
While there is some analysis here, we're not doing inference level stuff on the "if false" to knock out branches etc and generally that's not the kind of thing we try to do. On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal wrote: > > Hi, so I've been staring at this for hours : > > > (defn foo [] > (let [s (range)] > (if false > nil > (future > (loop [s s] > (recur (rest s))))))) > > > ...if I run this I run out of heap space quite fast on any of these: > > - Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0 > - OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS > > > ..that's what I have at hand for testing for now. If I remove the FUTURE > or place it higher up the stack it doesn't happen. I looked at a heap dump > in MAT and it seems to contain millions of empty stack frames or binding > frames (conveyor?); all held together by circular references (AFAICT). > > -- > Mvh, Lars Rune Nøstdal > https://www.quanto.ga/ > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
