[m-rev.] more LLDS accurate GC fixes

[Fergus Henderson]

On 15-Oct-2003, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> On Tue, Oct 14, 2003 at 02:34:59AM +1000, Fergus Henderson wrote:
> 
> > runtime/mercury_deep_copy_body.h:
> > 	Don't abort when trying to copy foreign types,
> > 	unless the foreign type happens to point into the Mercury heap.
> 
> Excuse my not looking too hard at the nature of this change; I'll just
> ask a question to which hopefully the answer is simply "not a problem".

Sure.  By all means, go ahead and ask such questions.
If in doubt, it's much better to ask!

> Could this create a problem for foreign types that are pointers, where
> the implementor of the foreign code was using uniqueness on the mercury side
> to keep a pure semantics?

Yes, this could indeed create a problem.  Good point.

> I.e. does it allow the following code to run without a runtime error?
> 
> 	copy(!.Ptr, !:PtrCopy),
> 	write_to_the_memory_pointed_to_by(!Ptr),
> 	read_from_the_memory_pointed_to_by(!.PtrCopy, X)
> 
> where
> 
>   :- mode write_to_the_memory_pointed_to_by(di, uo) is det.
>   :- mode read_from_the_memory_pointed_to_by(ui, out) is det.

Yes.

A reasonably straightforward solution to this problem is to modify
my change so that copying of foreign types is allowed when doing
partial copies (copying only the memory within a given region,
which is delimited by non-NULL lower_limit and upper_limit parameters
to MR_(agc_)deep_copy()), but to disallow copying of foreign types when
we're trying to do a complete copy (with builtin.copy/1, which
calls MR_deep_copy() with NULL for the lower_limit and upper_limit
parameters). 

In other words, let foreign types be copied by the Mercury implementation
when it needs to, because we know that is safe, but do not let them be
copied by Mercury programmers calling builtin.copy/1.

I will post a revised version of my patch and/or a relative diff
which does this.

However, that is not a complete solution to the issue that you have
raised.  In general, we want to be able to copy some foreign types
(e.g. io__stream), but not others (e.g. as in your example above).
Really we need some mechanism for users who are defining a foreign
type to specify whether or not it is copiable.

> what is the right way of implementing a foreign
> type too big for pass-by-value, or for variable-size foreign types?

For foreign types which are bigger than a pointer, the Mercury
implementation will box/unbox them at the language interface barrier.
So for medium-sized types, just use `pragma foreign_type' directly
and don't worry too much about the cost of copying, since they will
only be copied at the language interface barrier, not at every Mercury
procedure call.

For extremely large types, or for large types which will cross the
language interface barrier very frequently, it may be more efficient to
use a pointer rather than using the type directly.  However, this can
make memory management more complicated.

For variable-size foreign types... well, none of the languages that
we currently support interfacing with have any direct support for
variable-sized types.  In those languages, variable-sized objects
always have to be addressed via pointers.  So then you're in the
same situation as in the previous paragraph.

Oh, hang on, I forgot -- although C#, IL, MC++, and C89 don't support
variable sized types, C99 and GNU C do support variable-sized arrays
types, whose size can be dependent on e.g. the value of a global variable.
For those, the situation is the same as for fixed-sized types, except
that if the size varies *during* the execution of the Mercury code which
is manipulating them, then things are not likely to work.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------