[m-dev.] MR_GC_check

[Fergus Henderson]

On 03-Mar-2003, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> I believe we currently invoke MR_GC_check before each allocation.  It
> occurrs to me that apart from foreign code that allocates space on the
> heap (e.g. array), there is an easily calculable upper bound on the
> amount of memory that will be directly allocated by a procedure.  We
> could therefore replace many MR_GC_checks with a single check in the
> procedure prologue (and possibly before any directly recursive calls.)
> 
> Is this the case?

Yes.  If you check in the procedure prologue (inside the loop for
directlyrecursive tail calls, if any) it is not necessary to check before
directly recursive calls.

> Would it be hard to do?

Probably not that hard.  But let's get it working properly before we
worry too much about optimization.  Accurate GC still doesn't handle type
classes, and it doesn't try to expand the original heap size.

> Could we expect much in the way of a pay off?

For the optimization exactly as stated above? 
Some, but IMHO probably not a huge amount.
In some cases doing it that way can be a loss.
For example, if a procedure body consists of a switch
with 10 cases, and two of the cases contain a call to MR_GC_check,
then combining these into a single call in the procedure prologue
reduces code space but increases execution time for 8 of the 10 cases.

If the compiler is a bit smarter about it -- for example, only
combining such calls when every branch is guaranteed to execute
at least one MR_GC_check(), and doing it at the level of subgoals
rather than only one entire procedures -- it would be better.

I do think this optimization is worth doing at some point.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------