On Tuesday, 13 September 2016 at 19:30:16 UTC, Marco Leise wrote:
Am Tue, 13 Sep 2016 18:16:27 +0000
schrieb Laeeth Isharc <[email protected]>:
Thanks you for the clear explanation. So if you don't have
GC allocations within RC structures and pick one or the other,
then the concern does not apply?
That's right. Often such structures contain collections of
things, not just plain fields. And a list or a hash map working
in a @nogc environment typically checks its contained type for
any pointers with hasIndirections!T and if so adds its storage
area to the GC scanned memory to be on the safe side.
That means every collection needs a way to exempt its contents
from GC scanning and the user needs to remember to tell it so.
A practical example of that are the EMSI containers, but other
containers, i.e. in my own private code look similar.
https://github.com/economicmodeling/containers
struct DynamicArray(T, Allocator = Mallocator, bool supportGC
= shouldAddGCRange!T)a certain
{
...
}
Here, when you use a dynamic array you need to specify the type
and allocator before you get to the point of opting out of GC
scanning. Many will prefer concise code, go with GC scanning to
be "better safe than sorry" or don't want to fiddle with the
options as long as the program works. This is no complaint, I'm
just trying to draw a picture of how people end up with more GC
scanned memory than necessary. :)
Thanks, Marco.
So to a certain extent it's a problem of perception and of
cognitive load when one is coming to the language - none of the
steps taken together is necessarily difficult, but cumulatively
it's a lot to take in or figure out yourself - then, as you say
people do what's easy or manageable, and then those habits come
to constitute ones sense of what's implied by the language and
implementation when that's not necessarily right.
There's a great blog post to be written on getting along with and
without the GC for fun and profit - showing how to do the things
you discussed,comparing the amount of GC D generates with eg Java
to make vivid and concrete just how the situation is different,
illustrating how one can use the allocator for significant
allocations alongside the GC for trivial ones, illustrating how
to pre allocate buffers, and finally demonstrating how in
practice to use the GC profiling instrumentation we have.
Or perhaps rather a series of blog posts. It would be helpful
there to get across how the situation has improved. Because the
topic is almost guaranteed to come up in social media discussions
(which matter as when people Google for it that is often what
they will find), and we live in an age where the complexity means
people use heuristic thinking, and you can hardly blame them
when there is no one place to point them too (as we have for
ranges, slices etc).
I would write it myself if I had time and understood better not
just garbage collection techniques, but also how other languages
are in practice. But it's not something for me at this point,
and so someone else will have to do so. I will see when it is a
bit quieter in a year or two if someone that works with me wants
to do it, but in the meantime it's a great opportunity to
improve the messaging.
The wiki could also be a bit clearer last I looked on low-GC
solutions. Eg you won't easily find EMSI containers from a
casual browse.
Walter has mentioned the value as a technology professional from
blogging and having a personal page and I think that is right.
Laeeth
