On Tuesday, 19 September 2017 at 14:34:10 UTC, Mike Parker wrote:
On Tuesday, 19 September 2017 at 14:22:21 UTC, Craig Black
wrote:
Thank you for your response. The @nogc attribute is good, but
in my opinion it is incomplete if all types still require
scanning. The purpose of not employing GC in certain sections
of code is performance, and we are sacrificing performance
with every allocation unit that is needlessly scanned.
-Craig
As I wrote in my previous post, *no* GC activity will happen
inside a @nogc function. The only time any scanning or
collections can take place is when a allocation is requested.
If none are requested, there's no activity.
Aside from that, there are other options. If you don't want
your Foo member variable to be scanned, then allocate it
outside the GC heap (see Mallocator in std.allocator). You can
call GC.disable whenever you want (but be wary of the impact
performance when you later call GC.collect). You can allocate
outside of your hot loops and use stack allocation where
possible.
I suggest you take a look at the ongoing GC series on the D
Blog. The next post (coming later this week) covers heap
allocations.
https://dlang.org/blog/the-gc-series/
Thank you for the information. What I would like to do is to
create an Array template class that doesn't use GC at all.
Unfortunately I don't think this is possible with D in its
current state, at least not safely anyway. As it is, I can't
prevent someone using my Array template to create an array of
objects that reference the GC heap. This means that in order to
not break the language and avoid memory leaks, I am forced to
tell the GC to scan all of my allocations. There seems to be no
way to avoid this unnecessary overhead.
I realize that the GC will not collect during a @nogc function.
This is a good guarantee, but I want to reduce the amount of time
it takes to perform a collection, and there doesn't seem to be a
good way to do this.
-Craig
