www.digitalmars.com         C & C++   DMDScript  

D - GC deactivation

reply "zorro" <z z.com> writes:
Hi,

Is there a way to program without in D without the GC?

Thanks,
Denis
Nov 11 2002
next sibling parent "zorro" <z z.com> writes:
heu, I mean, in D without the GC....
Tired already :-(

"zorro" <z z.com> wrote in message news:aqq8ii$2crd$1 digitaldaemon.com...
 Hi,

 Is there a way to program without in D without the GC?

 Thanks,
 Denis

Nov 11 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
zorro wrote:

 Is there a way to program without in D without the GC?

You could avoid allocating anything or import the malloc/realloc/free symbols. Or you can keep the GC from collecting using: import gc; gc.disable (); // Turn collecting off. gc.enable (); // Turn it on. However, here's a dirty secret: it's ignored by the current collector. It doesn't matter much anyway, as the only time it runs the collector manually appears to be when it's out of memory, which will occur at the end of a long virtual memory swap.
Nov 12 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:aqqq3h$2v7r$1 digitaldaemon.com...
 zorro wrote:

 Is there a way to program without in D without the GC?

You could avoid allocating anything or import the malloc/realloc/free symbols. Or you can keep the GC from collecting using: import gc; gc.disable (); // Turn collecting off. gc.enable (); // Turn it on. However, here's a dirty secret: it's ignored by the current collector. It doesn't matter much anyway, as the only time it runs the collector manually appears to be when it's out of memory, which will occur at the end of a long virtual memory swap.

Which is a sad thing. My problem with any non-ref-count GC implementation is that it assumes that you have all the phisical/logical memory to spend. Which is not ethical behaviour in a multitasking enviroment. A D-compiled executable may hold a large chunk of garbage memory, disabling other application to use the same memory for running more smoothly. Any real GC should be somehow connected to the OS, and be notified, when other processes need the garbage memory. IMHO, this is something current OS-s don't support. So I am stuck with ref counting, or explicit deallocation. Yours, Sandor
Nov 13 2002
parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Sandor Hojtsy wrote:
You could avoid allocating anything or import the malloc/realloc/free
symbols.  Or you can keep the GC from collecting using:

     import gc;

     gc.disable (); // Turn collecting off.
     gc.enable (); // Turn it on.

However, here's a dirty secret: it's ignored by the current collector.
It doesn't matter much anyway, as the only time it runs the collector
manually appears to be when it's out of memory, which will occur at the
end of a long virtual memory swap.

Which is a sad thing. My problem with any non-ref-count GC implementation is that it assumes that you have all the phisical/logical memory to spend. Which is not ethical behaviour in a multitasking enviroment. A D-compiled executable may hold a large chunk of garbage memory, disabling other application to use the same memory for running more smoothly. Any real GC should be somehow connected to the OS, and be notified, when other processes need the garbage memory. IMHO, this is something current OS-s don't support. So I am stuck with ref counting, or explicit deallocation.

OS level garbage collection is the ideal, but working, good kernel level garbage collection has been a long time coming (dicounting LispOS), and I don't think that we will be able to count on it anytime soon. What is really needed, at this point, is more *real* control over the collector. We should be able to specifty min and max heap sizes, collection intervals, collection increments, nursery size, etc. The beltway system, which I mentioned in a previous post[1], presents a nice way of generalizing the frameworks of older collectors into a framework that can be switched about using run time variables. It isn't a perfect system, by any means, since it's possible to form a leaky collector with it, but given good default values, the beginner would be able to avoid messing with it, and the advanced user would be able to read the docs well enough to avoid any major errors. Maybe I'm just an obsessive performance freak, but I think that when large, critical pieces of software start getting written in D, it'll be that much easier if everyone doesn't have to rewrite the GC to get acceptable performance out of the app in the worst case. Evan 1) http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/beltway-pldi-2002.pdf
Nov 13 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:aqqq3h$2v7r$1 digitaldaemon.com...
 It doesn't matter much anyway, as the only time it runs the collector
 manually appears to be when it's out of memory, which will occur at the
 end of a long virtual memory swap.

The collector will run in preference to getting more memory from the OS. Only when it's wedged will it ask for more memory.
Nov 18 2002
parent sam41180 yahoo.com writes:
i think i differ from your thought about GC ,, it can becme active at any time i
have tried in one of my programs
i dont find any way of disabling gc
i user GC>KeepAlive(object)
to prevent GC from collecting required params passed to unmanaged code
Oct 25 2004