[m-dev.] Re: [mercury-users] tabling

[Fergus Henderson]

On 30-Nov-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 30-Nov-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > That's true for our currently supported implementations, i.e. for `--gc
> > conservative' and `--gc none', but for `--gc accurate' the implementation
> > that I posted won't work; ..
> 
> Of course, but MC don't *need* it to work with --gc accurate for now
> (since --gc accurate itself doesn't work yet ...).

Of course.  I think we're in violent agreement here ;-)

> > we'd need to use `c_pointer' rather than `int'
> > for the address type, and we'd need to teach the tabling implementation
> > how to table `c_pointer' values.
> 
> The problem with tabling values of type c_pointer is that Mercury doesn't know
> whether any particular use of c_pointer obeys the invariant required. This
> depends both on the garbage collector used and on the way the program uses
> the data structures pointed to by the pointer. The first the implementation
> can know about, the second it can't. The best it can do is take the
> programmer's word "no, I won't be updating the data structures reachable
> from the pointer after the pointer is tabled, except possibly in ways
> that make no observable difference (e.g. caching hints)". I would oppose
> any proposal to extend tabling to work on values containing c_pointers without
> requiring the programmer to make a declaration to this effect.

You've convinced me.  Treating object(T) specially would be a better
approach.

> > > In fact, any approach that requires the runtime to know about object(T)
> > > as a special type would impose distributed fat.
> > 
> > `c_pointer' already needs to be handled specially, so using
> > `c_pointer' rather than `int' for the address type would impose
> > no additional distributed fat.
> 
> Yes, because in that case it isn't object(T) that is special, but c_pointer.

With our current implementation approach, making `object(T)' special
would in terms of efficiency only require another element to the
MR_TypeCtorRep enum.  This would not impose any distributed fat other
the small amount of extra code space in the runtime for handling it
and the corresponding decrease in locality.  But any addition to the
runtime or the standard library costs similarly, at least for code
which is dynamically linked.  The cost would not be at all unreasonable,
IMHO.

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