Smart pointers instead of GC?

[Stewart Gordon]

On 25/12/2012 14:13, Sven Over wrote:
<snip>
> Also, garbage collection often tends to increase the memory footprint of
> your software.

ISTM you can't really make a like-for-like comparison, since non-GC 
programs vary a lot in how much they leak memory, which becomes almost a 
non-issue when you have GC.

I say "almost" because GC systems often aren't perfect.  For instance, a 
GC might mistake some sequence of four or eight bytes for a pointer and 
keep hold of the allocated memory it is pointing to.  Java has been 
known to leak memory in certain circumstances, such as not disposing a 
window when you've finished with it, or creating a thread but never 
starting it.

But there is something called packratting, which is a mistake at the 
code level of keeping a pointer hanging around for longer than necessary 
and therefore preventing whatever it's pointing to from being GC'd.

> You may be able to avoid this with some expert knowledge
> about the garbage collector, but this of course invalidates one of the
> main arguments in favour of GC, which is less complexity. I'd say that
> if you want to write memory- and CPU-efficient code, then you'll need a
> certain amount of understanding of your memory management. Be it your
> manual memory management, or the inner workings of your garbage collector.
>
> To cut things short, even after giving it a lot of thought I still feel
> uncomfortable about garbage collection.

That means you're uncomfortable about reference-counted smart pointers, 
because these are a form of garbage collection. :)

> I'm wondering whether it is
> viable to use the same smart pointer techniques as in C++: is there an
> implementation already of such smart pointers? Can I switch off GC in my
> D programs altogether? How much does the standard library rely on GC?
> I.e. would I have to write a alternative standard library to do this?

Good luck at getting your alternative library accepted as part of the D 
standard. :)

Seriously though, it's as much built-in language functionality as the 
standard library that relies on GC.  Any of the following will allocate 
memory from the GC heap:

- create anything with the 'new' keyword
- increase the length of a dynamic array
- concatenate arrays
- duplicate an array with .dup or .idup
- put data into an associative array

Which means sooner or later the garbage will need to be collected, 
unless the program is such that all memory allocation will be done at 
startup and then released only on exit.  Of course, whether the program 
can reasonably be written in this way depends on the nature of the program.

> There is one blog post I found interesting to read in this context,
> which also underlines my worries: http://3d.benjamin-thaut.de/?p=20

An interesting set of observations.  Looking at this one:
"Calls to the druntime invariant handler are emitted in release build 
also and there is no way to turn them off. Even if the class does not 
have any invariants the invariant handler will always be called, walk 
the class hirarchy and generate multiple cache misses without actually 
doing anything."

There seem to be two bugs here: that these calls are generated even in 
release mode, and that they are generated even if the class has no 
invariants.  One of us needs to experiment with this a bit more and get 
these issues filed in Bugzilla.

Stewart.