manual memory management

[H. S. Teoh]

On Tue, Jan 08, 2013 at 02:57:31AM +0100, Rob T wrote:
[...]
> So if the GC cannot be removed fully, then there's no point trying
> to fully remove it, and performance issues have to be solved through
> improving the GC implementation, and also with better selective
> manual control methods.

I know people *have* tried to use D without GC-dependent features; it
would be great if this information can be collected in one place and put
into the official docs. That way, people who are writing game engines or
real-time code know what to do, and the other 90% of coders can just
continue using D as before.


> As for the claims made that D's GC is "optional", that message is
> coming from various sources one encounters when reading about D for
> the first time.
> 
> For example:
> http://www.drdobbs.com/tools/new-native-languages/232901643
> "D has grown to embrace a wide range of features — optional memory
> management (garbage collection), ..."
> 
> Sure you can "optionally" disable the GC, but it means certain
> fundamental parts of the language will no longer be usable, leading
> to misconceptions that the GC is fully optional and everything can
> be made to work as before.

Does Dr. Dobbs allow revisions to previously published articles? If not,
the best we can do is to update our own docs to address this issue.


> I know D's documentation is *not* claiming that the GC is optional,
> you get that impression from reading external sources instead, however
> it may be a good idea to counter the possible misconception in the
> FAQ.

Yeah that's a good idea.


> Improved documentation will also help those who want to do selective
> manual memory management. As it is, I cannot say for certain what
> parts of the language require the use of the GC because the
> specification either leaves this information out, or is not specified
> clearly enough.
[...]

I don't know if I know them all, but certainly the following are
GC-dependent:

- Slicing/appending arrays (which includes a number of string
  operations), .dup, .idup;
- Delegates & anything requiring access to local variables after the
  containing scope has exited;
- Built-in AA's;
- Classes (though I believe it's possible to manually manage memory for
  classes via Phobos' emplace), including exceptions (IIRC);
- std.container (IIRC Andrei was supposed to work on an allocator model
  for it so that it's usable without a GC)

AFAIK, the range-related code in Phobos has been under scrutiny to
contain no hidden allocations (hence the use of structs instead of
classes for various range constructs). So unless there are bugs,
std.range and std.algorithm should be safe to use without involving the
GC.

Static arrays are GC-free, and so are array literals (I *think*) as long
as you don't do any memory-related operation on them like appending or
.dup'ing. So strings should be still somewhat usable, though quite
limited. I don't know if std.format (including writefln & friends)
invoke the GC -- I think they do, under the hood. So writefln may not be
usable, or maybe it's just certain format strings that can't be used,
and if you're careful you may be able to pull it off without touching
the GC.

AA literals are NOT safe, though -- anything to do with built-in AA's
will involve the GC. (I have an idea that may make AA literals usable
without runtime allocation -- but CTFE is still somewhat limited right
now so my implementation doesn't quite work yet.)

But yeah, it would be nice if the official docs can indicate which
features are GC-dependent.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy