Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Richard Jones <rich@annexia.org>
To: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
Cc: David Allsopp <dra-news@metastack.com>,
	'caml-list List' <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] problem creating .cma library
Date: Sat, 9 Jan 2010 12:52:24 +0000	[thread overview]
Message-ID: <20100109125224.GC26610@annexia.org> (raw)
In-Reply-To: <4B486974.7060007@citycable.ch>

On Sat, Jan 09, 2010 at 12:33:08PM +0100, Guillaume Yziquel wrote:
> David Allsopp a écrit :
> >Guillaume Yziquel:
> >
> >>So, no allocation of OCaml values (or in place modification, either, I
> >>guess) implies no need for CAMLparam/CAMLreturn stuff?
> >
> >Chapter 18 of the manual in Section 18.5 describes pretty much everything 
> >you need to know about writing safe stubs that work with the garbage 
> >collector.  
> 
> Yes. It is all I need to know to write safe stubs. But it does not 
> answer the question above. It does state that you do not need 
> registration of the result value if there's no allocation going on 
> between the moment result get its value and the return statement. But it 
> does not say when you can avoid CAMLparam macros.

The basic problem is that whenever you do an allocation, the allocator
might need to run the garbage collector.  Allocations from the minor
heap are normally quick (just comparing and decrementing a pointer),
but once the minor heap runs out a minor heap collection has to be
done, and that implies a slice of major heap collection too.

Why is this a problem?  Because you might in your C code have some
value on the stack.  'value' is (or can be) a pointer.  The OCaml
garbage collector can move pointed-to-objects around, firstly from the
minor heap to the major heap, secondly when compacting the major heap.
So your C value (pointer) *could* become an invalid pointer if what it
was pointing to got moved.

The way to avoid this small chance is to register the value with the
garbage collector, which is essentially what the CAMLparam* and
CAMLlocal* macros do.  So if the GC needs to move that object, it will
update the pointer for you.

If your function never allocates (and never calls anything which
allocates), then you don't need to register values, because no
allocation => they can't be moved.  [In fact there are some other
exceptions as well where you can prove that an allocation won't move
your pointer, eg. if you only allocate one thing and immediately
return the value.]

However it's always safe to use the macros, even if you're not
allocating, albeit a tiny little bit slower.

You might find my series on the garbage collector interesting if you
want to look into this further:

http://rwmj.wordpress.com/?s=ocaml+internals

Also if you are calling C functions which don't allocate from OCaml
code, you might want to read about noalloc:

http://camltastic.blogspot.com/2008/08/tip-calling-c-functions-directly-with.html

> By the way, here's a question I've been wondering about this section. 
> Rule 3: When I have a Abstract_tag block used to wrap a pointer in the C 
> heap, it seems to me that you can just do it with a Field(v,0)= 
> assignment. Do you need Store_field for that?

This is to do with the Remembered Set.  See part 5 of the above
series.

Rich.

-- 
Richard Jones
Red Hat


  reply	other threads:[~2010-01-09 12:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-30 17:48 rouanvd
2009-12-30 23:30 ` [Caml-list] " Guillaume Yziquel
2010-01-05 13:04   ` Damien Doligez
2010-01-08 23:38     ` Guillaume Yziquel
2010-01-08 23:54       ` Basile STARYNKEVITCH
2010-01-09  0:11         ` Guillaume Yziquel
2010-01-09  7:58           ` David Allsopp
2010-01-09 11:33             ` Guillaume Yziquel
2010-01-09 12:52               ` Richard Jones [this message]
2010-01-09 14:00                 ` Daniel Bünzli
2010-01-09 14:02                   ` Daniel Bünzli
2010-01-09 14:21                     ` Joel Reymont
2010-01-09 19:36                   ` Guillaume Yziquel
2010-01-10  2:11                     ` Daniel Bünzli
2010-01-11 17:14                       ` Guillaume Yziquel
2010-01-10 13:31                     ` ygrek
2010-01-11 18:01                       ` Guillaume Yziquel
2010-01-09 19:29                 ` Guillaume Yziquel
2010-01-11 12:18                   ` Gerd Stolpmann
2010-01-11 17:11                     ` Guillaume Yziquel
2010-01-20 14:42                   ` Damien Doligez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100109125224.GC26610@annexia.org \
    --to=rich@annexia.org \
    --cc=caml-list@yquem.inria.fr \
    --cc=dra-news@metastack.com \
    --cc=guillaume.yziquel@citycable.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox