[m-dev.] Trailing

[Bart Demoen]

> 	void MR_trail_value(Word *address, Word value)
> 	{
> 	    static Word *old_max_fr = NULL;
> 
> 	    if (MR_current_choicepoint() != old_max_fr) {
> 		MR_trail_function(untrail_values, (Word)cur_val_tr_ptr);
> 		old_max_fr = MR_current_choicepoint();
> 	    }
> 	    cur_val_tr_ptr->address = address;
> 	    cur_val_tr_ptr->value = value;
> 	    ++cur_val_tr_ptr;
> 	}
> 
> 
> 	static void untrail_values(Word datum, MR_untrail_reason reason)
> 	{
> 	    struct value_trail_entry *bottom;
> 
> 	    if (reason == MR_undo || reason == MR_exception) {
> 		while (bottom <= --cur_val_tr_ptr) {
> 		    *(cur_val_tr_ptr->address) = cur_val_tr_ptr->value;
> 		}
> 	    }
> 	    cur_val_tr_ptr = bottom;
> 	}

you probably want to reset old_max_fr on backtracking as well ?

another point: if functions and "regular" trailings are pushed on the
same stack, and executed/undone in reverse order of pushing, there is
possibly a different behaviour from your schema or the 2 stacks schema
in which this order is not respected; is that acceptable ?

> So the cost tradeoff is that trailing a value becomes more expensive (a
> conditional branch which will probably usually be taken

you have shifted some of the overhead of having tagged entries on one
trail stack from untrailing to trailing - is it really better ?

>     2.  It would be nice if there was a mechanism to avoid multiple
> 	untrailings in immediate succession.  Eg, suppose we've been
> 	making one copy of a whole array for each choicepoint.  If a
> 	failure takes us back a few choicepoints, it would be nice if
> 	we could just put back the right copy of the array, rather
> 	than copying back the array once for each choicepoint.  I hope
> 	this is clear.  I wish I could draw a picture and wave my
> 	hands around to explain this.

the mutables from SICStus 3.0 can be an inspiration for this

>     3.  Accurate garbage collection.  Firstly, the garbage collector
> 	needs to trace through the trail entries (both the function
> 	and value trails).

that is common and not problematic

> Also, it would be nice if after garbage
> 	collection, trail entries that specify how to restore garbage
> 	terms could be removed from the trails.  This seems fairly
> 	important, as doing this will sometimes mean that on the next
> 	garbage collection, some stuff that was only accessible from
> 	the trail can now be reclaimed.

it is possible to do it in such a way that these garbage terms don't
even survive the first gc; but as the functions on the trail stack can
be used for whatever purpose, it cannot be known whether a garbage
term is going to be restored by the function, or whether it is just
going to do something stupid (like printing) with an otherwise
unreachable term; in its full generality, you would need the
possibility to call the function with as calling_reason MR_gc ...
or is the use of MR_trail_function restricted to what the
implementation provides ?

Bart