Fix wording as suggested in #666

Mention reference counting in overview.
Also fix whitespace.

garbage.dd

@@ -2,17 +2,16 @@ Ddoc
 
 $(SPEC_S Garbage Collection,
 
-	$(P D is a systems programming language with support for a garbage collector. Usually it is not
-	necessary
+	$(P D is a systems programming language with support for garbage collection.
+	Usually it is not necessary
 	to free memory explicitly. Just allocate as needed, and the garbage collector will
 	periodically return all unused memory to the pool of available memory.
 	)
 
 	$(P D also provides the mechanisms to write code where the garbage collector
-	is not involved. Specially important for the use cases where performace requirements forbid such use. More information
-    provided below.
+	is $(B not involved). More information is provided below.
 	)
-    
+
 	$(P C and C++ programmers accustomed to explicitly managing memory
 	allocation and
 	deallocation will likely be skeptical of the benefits and efficacy of
@@ -108,13 +107,14 @@ $(SPEC_S Garbage Collection,
 	)
 
 	$(P These constraints are addressed by techniques outlined
-	in $(DPLLINK memory.html, Memory Management). Including the mechanisms provided by
-    D to control allocations outside the GC heap.
+	in $(DPLLINK memory.html, Memory Management), including the mechanisms provided by
+	D to control allocations outside the GC heap.
 	)
 
 	$(P There is currently work in progress to make the runtime library free of GC heap allocations,
-    to allow its use in scenarios where the use of GC infrastructure is not possible.
+	to allow its use in scenarios where the use of GC infrastructure is not possible.
 	)
+
 $(H2 How Garbage Collection Works)
 
 	$(P The GC works by:)
@@ -133,7 +133,7 @@ $(H2 How Garbage Collection Works)
 
 	$(LI Freeing all GC allocated memory that has no active pointers
 	to it and do not need destructors to run.)
-	
+
 	$(LI Queueing all unreachable memory that needs destructors to run.)
 
 	$(LI Resuming all other threads.)

overview.dd

@@ -100,7 +100,7 @@ $(SECTION3 Major Design Goals of D,
 	for third party static code checkers.)
 
 	$(LI Support memory safe programming.)
-	
+
 	$(LI Support multi-paradigm programming, i.e. at a minimum support
 	imperative, structured, object oriented, generic and even
 	functional programming paradigms.)
@@ -133,7 +133,7 @@ $(SECTION3 Major Design Goals of D,
 	technology.)
 
 	$(LI Cater to the needs of numerical analysis programmers.)
-    
+
 	$(LI Obviously, sometimes these goals will conflict. Resolution will be
 	in favor of usability.)
     )
@@ -218,6 +218,13 @@ $(SECTION3 Features To Keep,
 	software.
 	)
 
+	$(LI $(B Custom memory management).
+	There are times in systems programming where developers need
+	alternatives to garbage collection. D also allows for manual memory
+	management, techniques such as reference counting, and the use of 
+	specialized memory allocators.
+	)
+
 	$(LI $(B Down and dirty programming). D retains the ability to
 	do down-and-dirty programming without resorting to referring to
 	external modules compiled in a different language. Sometimes,
@@ -226,12 +233,6 @@ $(SECTION3 Features To Keep,
 	and dirty programming, but to minimize the need for it in
 	solving routine coding tasks.
 	)
-
-	$(LI $(B Use of allocators and manual memory management).
-	There are many use cases in systems programming where developers need to go beyond what
-	the garbage collector offers. For those use cases, D also allows for manual memory management
-	and the use of specialized memory allocators.
-	)
 	)
 )