[m-rev.] for post-commit review: clarify description of Boehm

[Julien Fischer]

On Fri, 30 Aug 2019, Zoltan Somogyi wrote:

> For review and edit by anyone.

> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index d8c5508d4..84fbd8193 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi
> @@ -8996,19 +8996,33 @@ is in general implementation-dependent.
>  The current Mercury implementation
>  supports two different methods of memory management:
>  conservative garbage collection, or no garbage collection.
> -(With the latter method, heap storage is reclaimed only on backtracking.)
> +The latter is suitable only for programs
> +with very short running times (less than a second),
> +which makes the former the standard method for almost all Mercury programs.
>
>  Conservative garbage collection makes inter-language calls simplest.
> -When using conservative garbage collection,
> -heap storage is reclaimed automatically.
> -Pointers to dynamically-allocated memory can be passed to and from C
> -without taking any special precautions.
> +The conservative garbage collector
> +has its own set of functions for allocating memory blocks,
> +such as @samp{MR_GC_NEW}, which are documented in runtime/mercury_memory.h.

Wrap that last bit in @file.

> +Memory blocks allocated by these functions,
> +either in C code generated by the C compiler

s/C compiler/Mercury compiler/

> +or in C code hand written by programmers,
> +are automatically reclaimed when they are no longer referred to
> +either from the stack or from other memory blocks allocated by these functions.

Or from global variables.

> +Pointers to such memory blocks can be passed to and from C code freely
> +as long as (a) pointers to these blocks are stored nowhere else,

What do you mean by point (a)?

> and
> +(b) pointers to these blocks point to the first word of the block.
> +
> +Note that the conservative collector cannot and does not recover
> +memory allocated by other methods, such as @samp{malloc}.

Julien.