[m-dev.] Re: ML_expand: attempt to use UNUSED tag!

[Tyson Dowd]

On 30-Dec-1997, Fergus Henderson <fjh at cs.mu.oz.au> wrote:
> On 30-Dec-1997, Tyson Dowd <trd at cs.mu.oz.au> wrote:
> > 
> > I'm wondering if it's possible to not allocate new type_infos
> > in general, and just keep around the actual parameters.
> 
> You can do something that is somewhat like this; it is usually called a
> "structure-sharing" implementation.  The alternative, which we're
> currently using, is a "structure-copying" implementation.
> 
> Mark Jones's paper about the implementation of Gofer says
> that Gofer uses a structure-sharing implementation,
> with hand-coded memory management, and that this is very
> important for making the type checker efficient.
> 
> A structure-sharing implementation would still need to do memory
> allocation, though; the advantage is just that it only needs to
> allocate fixed-size units.

Do you have this paper online or a reference to it?
 
> Anyway, for the moment I have stuck with using structure-copying
> to implement substitution of type variables in make_type_info();
> to solve the memory leak, I keep track of the allocated memory
> in a linked list.  See the diff below.
> 
> --------------------
> 
> library/std_util.m:
> 	Fix a bug in ML_create_type_info():
> 	when searching for type parameters to substituting with their
> 	corresponding values, they were only looking at the top level
> 	of the type.  To get correct results, it is necessary to
> 	traverse recursively through all levels of the type.
> 
> runtime/mercury_deep_copy.c:
> 	Fix a bug similar to the one above in make_type_info().
> 	The fix is a bit more complicated, due to memory management
> 	issues --- we need to keep a linked list of all the memory
> 	cells we allocate so that we can free them when we're done.
> 
> 	Also avoid some duplicated code in mercury_deep_copy.c
> 	by introducing a new function deep_copy_arg().
> 
> 	And fix a bug in deep_copy_type_info(): it should be
> 	allocating memory using incr_saved_hp(), not using
> 	make(). make() calls newmem(), which in non-conservative GC
> 	grades calls malloc(), which results in a memory leak;

What do you mean by memory leak? The memory was freed immediately after use.

If you're going to change the memory management, you'll need to
update the documentation (which still talks about using malloc)
in both files.

> 	whereas incr_saved_hp() allocates on the Mercury heap,
> 	which is (in accurate gc grades) subject to garbage collection.
> 

It's going to be difficult to use deep_copy to do accurate gc then.

The change looks mostly ok, but I'd like to discuss the memory
management before reviewing it more carefully.

-- 
       Tyson Dowd           # If I'm unusually agressive in this email, it's
                            # probably because USENET has been down here for
     trd at cs.mu.oz.au        # over a week, and I'm missing my usual dosage
http://www.cs.mu.oz.au/~trd # of flamewars. My apologies in advance.