Garbage Collector?
ag0aep6g via Digitalmars-d
digitalmars-d at puremagic.com
Thu Apr 27 13:09:44 PDT 2017
On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
> Frankly seeing in this example that the GC was in theory able
> to kick in 6 times in a simple 100 item loop, that is not
> efficient. I if did my own memory management, the variable
> cleanup will have been done in one go, right after the loop.
> Simply more efficient.
You can easily disable automatic collections and trigger one
manually:
----
import core.memory: GC;
GC.disable(); /* disable automatic collections */
/* ... do your loop ... */
GC.collect(); /* manually trigger collection */
GC.enable(); /* enable automatic collections */
----
> Been thinking about this topic. Dlang has a destructor, does
> that means if you allocate on the GC and then do your own
> destructor, it technically counts as manual memory management?
I'm not sure what role the destructor supposedly plays here. A
destructor is called automatically when the object is freed, or
you can call it manually with `object.destroy` [1]. Freeing
happens when the object is collected, or you can use
`core.memory.GC.free` [2] to free without collecting. Collecting
happens automatically, or you can trigger it with
`core.memory.GC.collect` [3] as shown.
You can use a destructor to manage memory owned by the object.
But the destructor being there doesn't affect how the object
itself is managed.
> That is assuming the GC removes the memory reference when you
> call it. I remember seeing in some other languages ( C#
> possibly? ) that referring a variable to be freed only meant
> the GC freed the memory when it felt like it, not the exact
> spot when you told it.
Destroying does not imply freeing. It's the other way around. If
you want to free, call `GC.free`. That does count as manual
memory management.
> I personally think that people simple have a bad taste with GC
> because they kick in too much outside there control. For 90%
> the default behavior is good but its those 10% that leaves a
> bad taste with people ( GC on critical moments and hurting
> performance in return ).
You can:
1) Call `core.memory.GC.disable` [4] if you don't want the GC to
collect for a while. You should make sure that you don't run out
of memory during that time, of course. Use
`core.memory.GC.enable` [5] to enable collections again.
2) Use the `@nogc` [6] attribute to forbid GC allocations in a
function. GC collections are only triggered by allocations (or
manually). So the GC won't kick in during execution of @nogc code.
[1] https://dlang.org/phobos/object.html#.destroy
[2] https://dlang.org/phobos/core_memory.html#.GC.free
[3] https://dlang.org/phobos/core_memory.html#.GC.collect
[4] https://dlang.org/phobos/core_memory.html#.GC.disable
[5] https://dlang.org/phobos/core_memory.html#.GC.enable
[6] https://dlang.org/spec/attribute.html#nogc
More information about the Digitalmars-d
mailing list