Without spending more time poking around, it's hard for me to say exactly 
what the problem is, and whether it's a bug, enhancement, or won't fix. 
Having written a lot of Clojure code in the 8 or 9 years, I've run into 
head holding problems a couple times maybe. In general, it's usually not an 
issue (and it's usually pretty obvious that something's wrong). In general, 
I would not be afraid of lazy seqs just because of this. Locals are 
automatically cleared, avoiding head holding, in the vast majority of cases 
you typically run into.

On Wednesday, February 6, 2019 at 12:27:21 PM UTC-6, Lars Rune Nøstdal 
wrote:
>
>
>
> On Wednesday, February 6, 2019 at 5:15:53 PM UTC+2, Alex Miller wrote:
>>
>> 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.
>>
>
> I.e. WONTFIX? Using lazy sequences is or can be pretty dangerous without 
> plenty and frequent testing, then -- since "don't hold onto the head" means 
> one will have to take into account whatever code the compiler and/or 
> libraries (c.c.async?) may or may not generate behind the scenes based on 
> subtleties. 
>
> Hmmmm ...anyway, I'll try to work around this; perhaps by avoiding lazy 
> sequences altogether. For me switching to clojure.core.async and doing 
> something like this *seems* to have worked (perhaps useful for others who 
> find this thread later):
>
>    - wrap the range (or infinite or long sequence really) in a *source* 
>    chan <https://clojuredocs.org/clojure.core.async/chan>.
>    - do the transformation in a *middle* chan; noting that the chan Fn 
>    takes an xform arg.
>    - pipe <https://clojuredocs.org/clojure.core.async/pipe> the *middle* chan 
>    to your final *output* chan. something like: *(async/pipe 
>    (handle-source-chan (async/chan 1000 xform) ...) output-chan)*
>
> ...it's a bit tricky to setup -- but yeah; no leaks here for now. It's 
> interesting that I have a sort of more explicit buffer in the *middle* chan 
> I can fiddle around with too now!
>
> Mvh, Lars
>
>  
>
>>
>>
>> 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.

Reply via email to