Thanks, both for the summary and for the link. Will try to go through it.<br><br>Regards,<br>Abhay<br><br><div class="gmail_quote">On Wed, Apr 16, 2008 at 12:37 PM, Bulat Ziganshin <<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello Abhay,<br>
<div class="Ih2E3d"><br>
Wednesday, April 16, 2008, 10:51:07 AM, you wrote:<br>
<br>
> I am not saying that it should claim it as soon as it is unused;<br>
> all I am saying that as soon as a priority object becomes<br>
> unreferenced, it should be the first choice for collecting in the next collect.<br>
<br>
</div>on the GC, all unreferenced objects are collected. there is no<br>
difference which ones will be collected first - anyway program is<br>
stopped until whole GC will be finished<br>
<div class="Ih2E3d"><br>
> Further I was under the impression (I may be wrong) that it uses a<br>
> generational GC and therefore scans allocated memory incrementally;<br>
> not the whole at a time. Please correct me if I am wrong.<br>
<br>
</div>yes, it uses generational GC. data are first allocated in small 256k block<br>
and when it is filled, GC for this small block occurs. data that are<br>
still alive then moved to the global heap. this minor GC doesn't scan<br>
global heap. if it will do this, each minor GC will become as slow as<br>
major ones<br>
<br>
"Generational garbage collection for Haskell"<br>
<a href="http://research.microsoft.com/%7Esimonpj/Papers/gen-gc-for-haskell.ps.gz" target="_blank">http://research.microsoft.com/~simonpj/Papers/gen-gc-for-haskell.ps.gz</a><br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> Regards,<br>
> Abhay<br>
<br>
> On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin<br>
> <<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>> wrote:<br>
> Hello Abhay,<br>
><br>
> Wednesday, April 16, 2008, 9:30:34 AM, you wrote:<br>
><br>
> i think it will not work with current ghc GC - it scans entire<br>
> memory/nursery when garbage collected so anyway you will need to wait<br>
> until next GC event occurs<br>
><br>
<br>
>> Your mail gives me an idea, though I am not an iota familiar with<br>
>> compiler/garbage collector internals. Can we have some sort of<br>
>> internally maintained priority associated with allocated objects?<br>
>> The garbage collector should look at these objects first when it<br>
>> tries to free anything. The objects which hold other system<br>
>> resources apart from memory, such as file handles, video memory, and<br>
>> so on could be allocated as higher priority objects. Is such a thing possible?<br>
>><br>
>> 2008/4/16 Conal Elliott <<a href="mailto:conal@conal.net">conal@conal.net</a>>:<br>
>> Are Haskell folks satisfied with the practical necessity of<br>
>> imperatively & explicitly reclaiming resources such as file handles,<br>
>> fonts & brushes, video memory chunks, etc? Doesn't explicit freeing<br>
>> of these resources have the same modularity and correctness problems<br>
>> as explicit freeing of system memory (C/C++ programming)?<br>
>><br>
>> I wrote a lovely purely functional graphics library that used video<br>
>> memory to lazily compute and cache infinite-resolution images, and I<br>
>> found that I don't know how to get my finalizers to run anytime soon<br>
>> after video memory chunks become inaccessible. Explicit freeing<br>
>> isn't an option, since the interface is functional, not imperative (IO).<br>
>><br>
>> I guess I'm wondering a few things:<br>
><br>
>> * Are Haskell programmers generally content with imperative and<br>
>> bug-friendly interfaces involving explicit freeing/closing of resources?<br>
>> * Do people assume that these resources (or handling them frugally)<br>
>> aren't useful in purely functional interfaces?<br>
>> * Are there fundamental reasons why GC algorithms cannot usefully<br>
>> apply to resources like video memory, file descriptors, etc?<br>
>> * Are there resource management techniques that have the<br>
>> flexibility, efficiency, and accuracy of GC that I could be using for these other resources?<br>
>><br>
>> Thanks,<br>
>> - Conal<br>
><br>
>> 2008/4/14 Abhay Parvate <<a href="mailto:abhay.parvate@gmail.com">abhay.parvate@gmail.com</a>>:<br>
>> Hello,<br>
><br>
>> In describing the Handle type, the GHC documentation says (in the System.IO documentation):<br>
><br>
>> GHC note: a Handle will be automatically closed when the garbage<br>
>> collector detects that it has become unreferenced by the program.<br>
>> However, relying on this behaviour is not generally recommended:<br>
>> the garbage collector is unpredictable. If possible, use explicit<br>
>> an explicit hClose to close Handles when they are no longer<br>
>> required. GHC does not currently attempt to free up file<br>
>> descriptors when they have run out, it is your responsibility to ensure that this doesn't happen.<br>
><br>
>> But one cannot call hClose on Handles on which something like<br>
>> hGetContents has been called; it just terminates the character list<br>
>> at the point till which it has already read. Further the manual says<br>
>> that hGetContents puts the handle in the semi-closed state, and further,<br>
>><br>
>> A semi-closed handle becomes closed:<br>
>> if hClose is applied to it; if an I/O error occurs when reading<br>
>> an item from the handle; or once the entire contents of the handle has been read.<br>
>> So do I safely assume here, according to the third point above,<br>
>> that it's fine if I do not call hClose explicitly as far as I am<br>
>> consuming all the contents returned by hGetContents?<br>
><br>
>> Thanks,<br>
>> Abhay<br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
><br>
>><br>
><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Bulat mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br>
><br>
><br>
<br>
><br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="Wj3C7c">Best regards,<br>
Bulat mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br>
<br>
</div></div></blockquote></div><br>