Will the D GC be awesome?

[Chad J]

On 10/03/2012 05:26 PM, DypthroposTheImposter wrote:
> D is pretty cool, perhaps someday I can use it instead of C++ and have
> cool shit like fast build times, modules, no more bloody headers, sane
> templates, CTFE, UFCS etc
>
> But can the D GC ever be made:
>
> 1. precise
> 2. able to scale to large-ish data set(2gig+)

Others have already addressed these 2 points better than my knowledge.

> 3. No long stalls(anything over a couple millisecond(<3))

One of the cool things about D's memory management is that it has a lot 
of features that help you /avoid heap allocation/:

- Stack allocation.  Just about anything in D can be stack allocated. 
As long as you know that your memory won't need to survive past its 
scope, you should be able to put it in the stack.

- Array slices.  This can be used to reduce copying.  Many other 
languages seem to implement string slicing as a copy operation, which 
introduces allocations.

- Ranges allow you to traverse arbitrary containers /without/ first 
converting them into an array, thus avoiding copying allocations. 
(Exception: if you need random access on a range that doesn't support 
random access, then you may have to do this.)

- Preallocation with conventional malloc.  Any time you find yourself 
frequently allocating and freeing the same struct/object/whatever, then 
you may want to preallocate it and avoid the allocation/deallocation 
overhead.

Using these things is probably a much better strategy for real-time 
software than leaning on a GC.  There will probably be times when a GC 
is still all-too-convenient or perhaps even necessary (if you've ever 
looked at MMO code).  As long as you keep the GC stuff down to only what 
is strictly necessary, then it will probably do well.

Try to do array slicing in Java or C#.  You probably won't be able to do 
it.  You'll get string /copies/ and this will incur heap allocations in 
the GC heap.  Those languages /need/ good garbage collection to be 
performant because they abuse the poor GC heavily.

The one thing I find missing (as of a couple months ago, anyways) is 
reference counting.  For soft-real-time apps it would be nice if 
transitively-atomic types (ex: strings) could be reference counted. 
This would allow a lot of copy-on-write standard library functions to be 
called without incurring the wrath of the GC.  D is already so powerful 
at memory management in other regards that I won't be worrying about 
this unless it gets in my way some day.


>
> Q. Curious, would it be compacting?
>
> If not then I'm stuck not using it much--
>
> Which leaves me with structs, and lets just say D struct are not
> impressive--
>
>
> * Oh and on a totally unrelated note, D needs Multiple return values.
> Lua has it, it's awesome. D doesn't want to be left out does it?
>
> * OpCmp returning an int is fugly I r sad
>
> * why is haskell so much shorter syntax, can D get that nice syntax
> plssssssssss
>

I'll stick with the comments of others for these points too.

> STAB!
>

PAWNCH!