Re: Disabling the Garbage Collector
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?
Re: Disabling the Garbage Collector
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.
Re: Disabling the Garbage Collector
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
Re: Disabling the Garbage Collector
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.
Disabling the Garbage Collector
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.
Re: Disabling the Garbage Collector
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
Re: Disabling the Garbage Collector
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?
Re: Disabling the Garbage Collector
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
Re: Disabling the Garbage Collector
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.
