[mercury-users] Making a Mercury shared library

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Jun 7 16:34:53 AEST 2011

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

    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.

> However, putting stackbottom on the stack would mean either:
> -1- When calling ocaml_mercury_init, put stackbottom on the call stack,
> then somehow make a callback to OCaml code from within
> ocaml_mercury_init. This isn't so hard to do, but doing so means writing
> awkward OCaml code and unnatural linking of OCaml modules.
> -2- Write some C code that calls mercury_init() and then starts OCaml
> code independently. The latter means calling OCaml's equivalent of
> mercury_init() just after calling mercury_init.
> The second option seems the most robust solution, but I'd like to avoid
> it if possible. Moreover, in the user guide, it is written:
> 	"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.

> 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

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