[m-dev.] for design review: accurate GC for MLDS back-end

[Zoltan Somogyi]

On 25-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> % Basically what we do is to put all all local variables that might
> % contain pointers in structs, with one struct for each stack frame,
> % and chain these structs together.

"all all"

I think what you have there is fine for gc. However, it should not be too hard
to make the same infrastructure, slightly generalized, also support a future
hlc.debug grade.

The code that decides which variables go into the struct should have an option
to put *all* variables in the structure. We would want to turn on that option
for the debugger.

> % The fixed fields are as follows:
> %
> %	struct MR_StackChain {
> %		struct MR_StackChain *caller;
> %		void (*traverse_frame)(void *this_frame);
> %	};

This would need at least one more field for the debugger, so it should be
documented that the size of this structure may depend on the grade.

> % As an optimization, we don't bother allocating a struct for
> % functions that don't have any variables that might contain pointers.
> % We also don't bother allocating a struct for leaf functions that
> % don't contain any functions calls or memory allocations.
> % (XXX These optimizations are not yet implemented.)

And when they are implemented, they should have a switch the compiler can use
to turn them off in debug grades.

> One difficulty with this design that I've spotted so far is that computing
> type_infos may be difficult in an MLDS->MLDS transformation.

In the existing RTTI system, we associate only pseudo typeinfos with each
variable, not a typeinfo. Materializing typeinfos that may not be needed
during forward execution would be a speed hit, although I don't know how big.
(Keeping local variables in a structure is already a speed hit.) This aspect
of the system needs more thought; probably Tyson and I should discuss it
with you in person.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------