[m-dev.] [reuse] fixes of some naughty bugs
Fergus Henderson
fjh at cs.mu.OZ.AU
Tue Mar 13 02:27:05 AEDT 2001
On 12-Mar-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> Suppose we defined p/1 as:
>
> p(Term) :-
> Term = f(X, Y),
> X = Y,
> destructively update first argument of Term to be Y.
>
> If X and Y are big, this will free up a lot of space at the next GC. But
> Mercury compilers are allowed to reorder conjunctions, so there's no way
> for a programmer to write
>
> p(X), X = f(Y,_), q(Y)
>
> and be confident the X = f(Y,_) won't be moved before the call to p/1,
> thereby screwing up the GC possibility.
The programmer can always use --no-reorder-conj or its equivalent.
Or they can use if-then-else to force sequential evaluation in just
this particular spot. (Yes, a more syntactically convenient way of
forcing sequential conjunction would be nice.)
But normally the programmer should just trust the compiler to do
a reasonably good job. If reordering X = f(Y,_) to before the call to p/1
is going to slow the program down, then the compiler shouldn't do it.
Sure, the compiler *might* do it. But the compiler might also decide
to allocate every floating point value on a misaligned address that
causes a trap to the OS for every floating point access, or to generate
code for "hello world" that links in a 2 gigabyte Java library that
gets dynamically loaded from a web site in outer Mongolia via a 300-baud
modem. At some point you have to rely on quality of implementation.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
| 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
--------------------------------------------------------------------------
More information about the developers
mailing list