[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 08/12] libxl: ocaml: drop the ocaml heap lock before calling into libxl



On 29 Nov 2013, at 08:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> On Thu, 2013-11-28 at 18:11 +0000, Ian Jackson wrote:
>> Rob Hoes writes ("RE: [PATCH v6 08/12] libxl: ocaml: drop the ocaml heap 
>> lock before calling into libxl"):
>>> Ian Jackson wrote:
>>>> I don't see here how "async" is protected from being gc'd (or, perhaps,
>>>> moved by the ocaml gc) during the execution of the long-running libxl
>>>> operation.  The pointer to it is hidden inside the (now malloc'd) ao_how.
>>>> AIUI the "CAMLparam1...CAMLreturnT" pair protect it during the aohow_val
>>>> function ?
>>> 
>>> To keep the async user values "alive", we keep them in a set in
>>> OCaml for the duration of the async call. See the code that deals
>>> with "async_users" in xenlight.ml.in. The GC will definitely not
>>> destroy these values.
>> 
>> Surely that can't be right.  You're relying on the ocaml code to do
>> the memory management right.  Effectively you've made an unsafe
>> interface!
>> 
>>> I'm not sure if the GC may _move_ the value (I assumed it wouldn't)...
>> 
>> I thought GCs in these kind of languages were entitled to move things
>> to which they thought they had all the references.
> 
> Me too, and the ocaml books explicitly say that it will, e.g.
> http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora116.html
>        Any allocation in the Objective CAML heap can trigger a garbage
>        collection, which will deallocate unused memory blocks and may
>        move live blocks.
> 
> Does the gc have some sort of horror mode. where it would move stuff
> around at every allocation etc? Perhaps a debug option here to always
> manually invoke the gc when you acquire/drop the lock and in other key
> places?
> 
> I wonder if you need to use these functions:
>> /* [caml_register_global_root] registers a global C variable as a memory root
>>   for the duration of the program, or until [caml_remove_global_root] is
>>   called. */
>> 
>> CAMLextern void caml_register_global_root (value *);
>> 
>> /* [caml_remove_global_root] removes a memory root registered on a global C
>>   variable with [caml_register_global_root]. */
>> 
>> CAMLextern void caml_remove_global_root (value *);
> 
> To keep the for_callback value live?

Perhaps, yes, if a global root is something that is not only never deallocated, 
but also never moved. I remember we discussed this topic when revising v1 of 
the series, and I ended up with the current implementation that keeps a 
reference to the value at the ocaml level.

I wonder how ocaml tracks live values when they may move around. I’ll see what 
I can find out.

Rob


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.