www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Disabling the Garbage Collector

reply "Jeroen Bollen" <jbinero gmail.com> writes:
How to disable D's Garbage Collector? I have read stuff about
editing Phobos and simply take it out, and replace it with your
own to have stuff like the new keyword still work. Surely there
must be an easier way, where you can still allocate like you
normally would, as long as you deallocate too.

I've read about ways to disable the garbage collector, but that'd
mean it was initially enabled.
Mar 02 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jeroen Bollen:


 I've read about ways to disable the garbage collector, but 
 that'd
 mean it was initially enabled.


You can disable and then enable the garbage collector like this:

void main() {
     import core.memory;
     GC.disable;
     // Do stuff here.
     GC.enable;
}

But if you perform GC-managed operations, they will not free 
their memory, like array appending, array concat, inserts in 
associative arrays, and so on.

You can also stub away the GC in a more complex way.

Bye,
bearophile
Mar 02 2014
parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Sunday, 2 March 2014 at 23:17:12 UTC, bearophile wrote:

 Jeroen Bollen:


 I've read about ways to disable the garbage collector, but 
 that'd
 mean it was initially enabled.


 You can disable and then enable the garbage collector like this:

 void main() {
     import core.memory;
     GC.disable;
     // Do stuff here.
     GC.enable;
 }

 But if you perform GC-managed operations, they will not free 
 their memory, like array appending, array concat, inserts in 
 associative arrays, and so on.

 You can also stub away the GC in a more complex way.

 Bye,
 bearophile


That'd mean that the garbage collector was initialized in the 
first place, wouldn't it?

Is there maybe a way to disable the garbage collector from 
running unless you explicitly call it?
Mar 02 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jeroen Bollen:


 Is there maybe a way to disable the garbage collector from 
 running unless you explicitly call it?


I often seem to ask silly questions, but why do you need that?

Bye,
bearophile
Mar 02 2014
parent reply "Anonymouse" <asdf asdf.com> writes:
On Monday, 3 March 2014 at 01:48:23 UTC, bearophile wrote:

 Jeroen Bollen:


 Is there maybe a way to disable the garbage collector from 
 running unless you explicitly call it?


 I often seem to ask silly questions, but why do you need that?

 Bye,
 bearophile


To write tidy code? Much like const correctness, avoiding magic 
numbers and globals, not polluting namespace overly, only import 
what you need etc etc.
Mar 03 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Anonymouse:


 To write tidy code? Much like const correctness, avoiding magic 
 numbers and globals, not polluting namespace overly, only 
 import what you need etc etc.


In general avoiding the self initialization of the GC doesn't 
make your code more tidy. Totally not activating the GC is only 
for special situations and special D code.

Bye,
bearophile
Mar 03 2014
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 March 2014 at 23:21:49 UTC, Jeroen Bollen wrote:

 Is there maybe a way to disable the garbage collector from 
 running unless you explicitly call it?


That's really the default. The GC in D runs if and only if you do 
a GC allocation and there isn't enough memory in its existing 
pool. Then it tries to do a collection to make room (and if that 
fails, it asks the operating system for more memory to grow its 
arena, and if that fails, it throws OutOfMemoryError).

If you call GC.disable, it just sets a flag to skip the try 
collection step.


But, in any case, the GC doesn't sit around in the background 
constantly running at random times. It only runs when you call on 
it to allocate.
Mar 02 2014
parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Monday, 3 March 2014 at 02:33:49 UTC, Adam D. Ruppe wrote:

 On Sunday, 2 March 2014 at 23:21:49 UTC, Jeroen Bollen wrote:

 Is there maybe a way to disable the garbage collector from 
 running unless you explicitly call it?


 That's really the default. The GC in D runs if and only if you 
 do a GC allocation and there isn't enough memory in its 
 existing pool. Then it tries to do a collection to make room 
 (and if that fails, it asks the operating system for more 
 memory to grow its arena, and if that fails, it throws 
 OutOfMemoryError).

 If you call GC.disable, it just sets a flag to skip the try 
 collection step.


 But, in any case, the GC doesn't sit around in the background 
 constantly running at random times. It only runs when you call 
 on it to allocate.


If I were to compile without linking to the garbage collector, 
what would and what wouldn't work in D?
Mar 03 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 March 2014 at 12:23:49 UTC, Jeroen Bollen wrote:

 If I were to compile without linking to the garbage collector, 
 what would and what wouldn't work in D?


You can get almost everything to work, though some built-in 
features will need to be replaced/supplemented by library things 
and some care will be needed to avoid memory leaks.

Specifically:

* the a ~ b operator is a bad idea without the GC. (and with the 
GC in performance critical code)

* delegate closures are a bad idea without the GC (though you can 
make them work)

* Your classes will be written pretty differently

* ~=, .dup and .length on built in arrays will need to be 
replaced by a library thing


I think the rest can be made to work off the top of my head. 
Though, I think the cases where you want to go without the GC 
entirely are pretty rare. Normally, I'd just be careful about 
where you trigger it instead.
Mar 03 2014