[m-dev.] for review: implementation of --no-allow-hijacks

[Zoltan Somogyi]

>> Extend the new failure handling method to optionally preserve an invariant
>> required by accurate gc: always being able to tell with respect to what MR_sp
>> or MR_curfr to interpret the stackvars and framevars referred to by the label
>> whose address is the redoip slot of a nondet stack frame.
> 
> I don't understand that -- often the redoip slot will be `do_fail'.
> What happens in that case?

In that case, the stack frame is effectively not there. When execution
backtracks to that stack frame, it will remove the frame, and backtrack
to the one below. Therefore there are no roots reachable from a frame
with a do_fail redoip that are not reachable from the frames below it,
which means that such frames can be ignored by the garbage collector.
The simplest and fastest way to make this happen is to register a stack
layout for do_fail that says that there are no active variables. Any
variables still reachable from the call that created the do_fail stack frame
will be described by other stack frames below.

Note that accurate gc will need to be able to cope with multiple nondet stack
frames, one ordinary and the others temporary, referring to variables of the
same call via the layouts of their redoip labels, due to consecutive
disjunctions and the like.

(I believe we never store the address of any of the other labels from
the runtime in redoip slots, so this issue does not come up for them.)

> > tests/{general,hard_coded}/space.{m,exp}:
> > 	Move this test case from general to hard_coded.
> 
> You need to also modify tests/{general,hard_coded}/Mmakefile
> (probably you have, but the log message didn't say so).

The log message did mention hard_coded/Mmakefile. general/Mmakefile
did not need modification, because space.m was not enabled before.

> > tools/bootcheck:
> > 	If the -r option is given, remove the stage2/runtime directory
> > 	before creating it.
> 
> That one should probably be committed separately (indeed, I think you
> did commit it separately), so it shouldn't be part of the log message
> for this change.

Yes, you're right.

> > Index: tests/hard_coded/complex_failure.m
> > +
> > +% Note that NU-Prolog cannot execute this test case correctly. With -> ;
> > +% notation, NU-Prolog does a hard neck cut, which is not Mercury's desired
> > +% semantics; with the if-then-else notation, it delays the conditions
> > +% since they are not ground.
> 
> Why not use the `if some [OutputVar] ...' notation?

Because I did not think of that. Now that you have reminded me, I will add
this test case in tests/general.

Zoltan.