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