[mercury-users] Making a Mercury shared library

Guillaume Yziquel guillaume.yziquel at gmx.ch
Tue Jun 7 17:30:21 AEST 2011


Le Tuesday 07 Jun 2011 à 16:34:53 (+1000), Julien Fischer a écrit :
> 
> On Sun, 5 Jun 2011, Guillaume Yziquel wrote:
> 
> >For now, I'm hitting another problem concerning the stackbottom argument
> >of the mercury_init() function call. My code is:
> >
> >	#include <caml/mlvalues.h>
> >	#include <caml/alloc.h>
> >	#include "hello.mh"
> >
> >	static value stackbottom;
> >
> >	static char * mercury_args [1] = {"ocaml-mercury"};
> >
> >	CAMLprim value ocaml_mercury_init (value ml_unit) {
> >	        stackbottom = caml_alloc_small (1, 0);
> >	        caml_register_generational_global_root(&stackbottom);
> >	        mercury_init(1, mercury_args, &Field(stackbottom, 0));
> >	        return Val_unit;
> >	}
> >
> >	CAMLprim value ocaml_fibonacci (value ml_n) {
> >	        MR_Integer n = Long_val(ml_n);
> >	        MR_Integer fib_n;
> >	        fibonacci(n, &fib_n);
> >	        return Val_long(fib_n);
> >	}
> >
> >What I'm doing here is boxing stackbottom into an OCaml heap-allocated
> >block. This is very likely wrong, as I gather that stackbottom really
> >should be something on the stack.
> 
> It needs to be an address on the stack, preferably the address of the
> base of the stack, but defintely an address before any stack frames that
> contain pointers to Mercury terms.  For C or C++ programs that call
> Mercury code (or indeed Mercury programs compiled in one of the C grades)
> this is usually done by taking the address of a local variable in
> the main function, for example
> 
>    int
>    main(int argc, char **argv)
>    {
>       void *foo;
> 
>       mercury_init(argc, argv, &foo);
> 
>       ...
>    }
> 
> On most platforms you should also be able to pass 0 as the third
> argument of mercury_init and the collector will attempt to work out
> where the base of the stack is itself.

OK, I worked it out this way:

	#include <caml/mlvalues.h>
	#include <caml/callback.h>

	extern value mercury_stackbottom;

	int main (int argc, char ** argv) {

		void * stackbottom;
		mercury_stackbottom = (value) &stackbottom;

		caml_startup (argv);

		return 0;
	}

The mercury initialisation and termination calls are called by OCaml
modules, inside the caml_startup() invocation. The downside of this is
the unnatural build system, but this cannot really be helped.

> >	"stackbottom is the address of the base of the stack. In grades
> >	that use conservative garbage collection this is used to tell
> >	the collector where to begin tracing."
> >
> >This seems to suggest that if I chose the right garbage collecting
> >scheme for Mercury code, I might be able not to worry too much about
> >stackbottom. Which would be nice for starters.
> 
> I wouldn't read too much into that since in practice the only usable
> garbage collection scheme is the conservative** one.  (Any others are
> still too experimental for general use.)
> 
> ** specifically the one using the Boehm GC.

I'm somehow worried, nevertheless, about Boehm's GC confusing stuff in
Mercury stack frames and in OCaml stack frames. Is this a legitimate
worry?

> >So what GC mechanism would be satisfying? Do I really need
> >Mercury's GC around?
> 
> Mercury will require some for of garbage collection for all but trivial
> programs.

My long term concern is writing mixed ATS/Mercury code, and ideally I'd
like to use a common garbage collector, and avoid Boehm's GC. How hard
is it to plug in a foreign garbage collector into Mercury? I also
noticed there are parallel garbage collectors in Mercury. What does this
recover specifically?

> Julien.

-- 
     Guillaume Yziquel
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the users mailing list