|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |