[m-dev.] for review: implementation of --no-allow-hijacks
Tyson Dowd
trd at stimpy.cs.mu.oz.au
Wed Dec 31 01:11:59 AEDT 1980
On 29-Jul-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
>
> >> 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.
What will happen in these cases is that accurage GC will have already
deep copied the variables to the "to_heap", and overwritten its
value on the stack, and so it will notice straight away that this
variable is not on the "from_heap" and so need not be copied.
If there were discrepencies in the liveness sets, then eventually
the union of all the liveness sets will be copied.
--
Tyson Dowd # "Bill Gates is a white persian cat and a monocle
# away from becoming another James Bond villan."
trd at cs.mu.oz.au # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd # -- Dennis Miller and Terri Branch
More information about the developers
mailing list