[m-dev.] for review: direct retry

[Fergus Henderson]

On 10-Oct-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> For review by anyone.
> 
> The debugger's retry command at the moment works only from a final port for
> the call to be retried, the reason being that the RTTI does not have the
> information required to make sure that the state of the stacks is reset
> correctly. If you invoke retry from a non-final port, the current
> implementation skips forward to a final port and then does the retry;
> this does not work if you get a core dump or a infinite loop during the forward
> skip. This change adds the required info to the RTTI and thus enables
> direct retries from the middle of calls.
> 
> The information added has two components. First, if a procedure that lives on
> the nondet stack allocates any temporary nondet stack frames, then it must
> record the old value of maxfr in a stack slot so that retry can restore it.
> Second, if a procedure is tabled, then it must record the call table tip node
> corresponding to the actual input arguments, so we can reset this node to
> uninitialized (if we don't, then the retried call will find the active call
> marker and report an infinite loop error).
> 
> The support for retries across minimal model calls is not finished yet.
> Finding out what the right thing to do in such cases is a research project,
> one that cannot even be started until minimal model tabling works reliably
> in the *absence* of retries. However, such retries do grossly wrong things
> at the moment; this change is a definite improvement. It attempts to perform
> the retry from the fail port, since that is the only time when the minimal
> model tabling data structures are quiescent. The "fail" command I added to
> the debugger command set to let this be done is not complete yet and is
> therefore undocumented; the problem is that a call to a model_non predicate
> in a committed choice context will not get to the fail port. I added goal paths
> to return layouts so that we will eventually be able to tell when execution
> leaves a committed choice context surrounding an ancestor of a model_non
> predicate call, but this functionality is not yet implemented.
> 
> compiler/stack_layout.m:
> 	Generate the three new fields.

Which three new fields?
(From the description above, I only count two, and I'm not quite sure
about those...)

> compiler/hlds_goal.m:
> 	Add a goal feature which marks its goal as defining the variable
> 	representing the call table tip node.
> 
> 	Add a field to the goal path step representing quantification;
> 	the field says whether the quantification changes the determinism of
> 	the goal (i.e. whether it cuts away solutions).
> 
> compiler/hlds_pred.m:
> compiler/hlds_out.m:
> 	Add two fields to proc_infos which (a) record which variable, if any,
> 	holds the call table tip node, and (b) record whether the procedure's
> 	layout structure needs to reserve a slot for the saved value of maxfr.
> 
> compiler/table_gen.m:
> 	Put this feature on the appropriate goal.

I suggest s/this/the new goal feature/

> compiler/handle_options.m:
> 	Disable hijacks if debugging is enabled. This is required for the
> 	correctness of the code we use to restore the stacks for direct
> 	retries.

What about when you mix code which is compiled with debugging and
without debugging?  Does the direct retry code work correctly in
that case?

[I haven't looked at the diff yet, just at the log message.]

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------