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. 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. Regards, Abhay On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin 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 : 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 : 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:Bulat.Ziganshin@gmail.com

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 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.gzhttp://research.microsoft.com/%7Esimonpj/Papers/gen-gc-for-haskell.ps.gz

...

Regards, Abhay

...

On Wed, Apr 16, 2008 at 11:55 AM, Bulat Ziganshin 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 : 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 : 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:Bulat.Ziganshin@gmail.com

...

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Wed, 2008-04-16 at 11:00 +0530, Abhay Parvate wrote:

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?

The way I have imagined this when I've faced Conal's problem in the past (again to do with graphics libs and large foreign allocated bitmaps) is to assign an optional heap memory equivalent cost to ForeignPtrs. Basically the idea is to take the foreign memory allocations into account when considering heap pressure. At the moment a ForeignPtr only counts for about 10 words of heap pressure when of course it can represent hundreds of kilobytes. So by assigning a cost we can take that into account with the normal decisions about when to do a minor and major GC. We should be able to treat a ForeignPtr to foreign allocated memory in just the same way as a ForeignPtr to heap allocated memory in terms of timing/frequency of GC behaviour. Of course it doesn't help with all resources since not all are equivalent to memory, eg the arbitrary limits some OSs impose on the number of open file handles. Duncan