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

Re: camlSys__entry vs. FreeBSD kmod



On 11 Jul 2012, at 17:03, Anil Madhavapeddy wrote:

> On 11 Jul 2012, at 16:08, PALI Gabor Janos wrote:
> 
>> On Wed, Jul 11, 2012 at 03:23:30PM +0100, Anil Madhavapeddy wrote:
>>> the logic is in the OS.Main.run module in mirage-platform (which implements 
>>> an OS
>>> module for either POSIX or Xen at the moment, and will have an extra
>>> directory for kFreeBSD with your kernel-specific bindings in it).
>> 
>> Right, I then continue with the investigation of that.
>> 
>> 
>>> Summary: the callbacks working and executing code in the kernel is a very 
>>> good thing! :)
>> 
>> Yeah :-)
>> 
>> By the way: is there some de-initialization routine for the caml run-time?
>> After each kernel module unload, I got this fancy message:
>> 
>> Warning: memory type caml leaked memory on destroy (10 allocations, 1581136
>> bytes leaked).
>> 
> 
> Good question; can the unload function call a cleanup function?   It would be
> nice to be able cancel outstanding Lwt threads, and do a Gc.compact to free
> any external resources that have been locked.  Finally, we need to track all
> the memory allocated for the OCaml runtime and release that en-masse.  Can
> FreeBSD release all memory allocated to a particular pool?  I don't believe
> there is a caml_shutdown, but it is easy to modify the runtime to colour pages
> that are intended for the OCaml runtime (see byterun/memory.c)


Incidentally, as a random tip, you might find it helpful to define -DDEBUG, 
which
will activate internal heap sanity checks and run them regularly.  The default
Makefile builds libasmrund.a which has this already activated (and is otherwise
the same as libasmrun.a).

-anil


 


Rackspace

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