[m-dev.] Re: for review: new method of handling failures, part 1 of 6

[Zoltan Somogyi]

> > 	a fourth field that is set to the value of MR_sp. The idea is that
> > 	the runtime system, which will be able to distinguish between
> > 	ordinary frames (whose size is at least 5 words), 3-word and 4-word
> > 	temporary frames, will now be able to use the redofr slots of
> > 	all three kinds of frames and the fourth slot values of 4-word
> > 	temporary frames as the addresses relative to which framevars
> > 	and detstackvars respectively ought to be offset in stack layouts.
> 
> This doesn't appear to be documented anywhere (other than the log message).
> Perhaps somewhere in the notes/ would be a good idea.

It isn't documented elsewere because it isn't done yet. It will be documented
when it is implemented. The log message outlines future plans ("... will be
able ...").

> > runtime/mercury_imp.h:
> > 	If MR_DISABLE_REDOFR is defined, undefine off MR_USE_REDOFR before
> s/off/of/ ?

Actually, Fergus's approach to bootstrapping is better, so I'll delete this
part of the change.

> > 	% Create a code address which holds the address of the specified
> > 	% procedure.
> > 	% The fourth argument should be `no' if the the caller wants the
> > 	% returned address to be valid from everywhere in the program.
> > 	% If being valid from within the current procedure is enough,
> > 	% this argument should be `yes' wrapped around the value of the
> > 	% --procs-per-c-function option and the current procedure id.
> > 	% Using an address that is only valid from within the current
> > 	% procedure may make jumps more efficient.
> > 	% XXX
> 
> The 4th argument isn't a maybe, so the comment doesn;t match the decl.
> It might be a good idea to create a new type for this with more descriptive
> names.
> Is discrepancy the reason for this XXX?

It may be, but that is one part of the code I did not touch, so I will leave
it as it is for now.

> >  :- pred code_info__make_entry_label(module_info, pred_id, proc_id, bool,
> > 	code_addr, code_info, code_info).
> >  :- mode code_info__make_entry_label(in, in, in, in, out, in, out) is det.
> > 
> 
> > 	% note: we must be careful to apply deaths before births
> 
> I know I probably wrote this comment, but it doesn't say why. I assume
> that it is because a variable may have two lifetimes in adjacent 
> conjoined scopes or something. If you know the reason, could you
> improve the comment?

I don't know the reason. I suppose we could reverse the order, see what
breaks, and document that :-(

> > code_info__remember_position(position_info(C), C, C).
> > 
> > code_info__reset_to_position(position_info(PosCI), CurCI, NextCI) :-
> > 		% The static fields in PosCI and CurCI should be identical.
> > 	PosCI  = code_info(_,  _,  _,  _,  _,  _,  _,  _, 
> > 		LA, LB, LC, LD, LE, LF, _,  _,  _,  _,  _,  _ ),
> > 	CurCI  = code_info(SA, SB, SC, SD, SE, SF, SG, SH,
> > 		_,  _,  _,  _,  _,  _,  PA, PB, PC, PD, PE, PF),
> > 	NextCI = code_info(SA, SB, SC, SD, SE, SF, SG, SH,
> > 		LA, LB, LC, LD, LE, LF, PA, PB, PC, PD, PE, PF).
> 
> At one stage you talked about making the position info a structure just
> containing the fields of the code info that get remembered to force
> maintainers who add a field to code info to work out whether or not
> it should be remembered. Did you change your mind, or is that an item
> for further work.

The position_info() wrapper around the code_info does have the effect of
forcing programmers to make the distinction between the current code_info
and a remembered position. As for deciding where new fields go, I think
the comments in the declaration of the code_info type should be sufficient.
The design above requires the allocation and filling of only a one-word cell;
the design which has a specialized structure for positions has to allocate
and fill a seven-word cell.

The alternative design that would make the most sense would be to make
code_info have only three arguments, one each for the static,
location-dependent and persistent fields, and make position_info just be
the middle one of these. This design would require significantly fewer words
but more cells to be allocated for updates, and accesses would be slower.
Since memory profiling shows that code_infos do not account for a significant
fraction of memory consumption, I thought access time and calls to GC_malloc
were slightly more important. However, from a performance point of view
the various designs are pretty close.

What do you think?

> >  :- type disj_hijack_info
> > 	--->	disj_no_hijack
> > 	;	disj_quarter_hijack
> > 	;	disj_half_hijack(
> > 			lval		% the stack slot in which we saved
> > 					% the value of the hijacked redoip
> > 		)
> > 	;	disj_full_hijack(
> > 			lval,		% the stack slot in which we saved
> > 					% the value of the hijacked redoip
> > 			lval		% the stack slot in which we saved
> > 					% the value of the hijacked redofr
> > 		).
> 
> A couple of comments that describe the meaning of the constructors would
> be helpful here.

Is a reference to failure.html (e.g. quarter_hijack is "best case" etc),
enough here and in the other similar cases? I don't want to have to document
this scheme twice.

Zoltan.