From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 12A93BC57 for ; Tue, 30 Mar 2010 17:57:11 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.51,334,1267398000"; d="scan'208";a="48062200" Received: from estephe.inria.fr ([128.93.11.95]) by mail2-relais-roc.national.inria.fr with ESMTP; 30 Mar 2010 17:57:10 +0200 Message-ID: <4BB21F56.9070802@inria.fr> Date: Tue, 30 Mar 2010 17:57:10 +0200 From: Xavier Leroy User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: david.baelde@ens-lyon.org Cc: Goswin von Brederlow , Savonet's developpers list , Caml Mailing List Subject: Re: [Caml-list] Re: Random segfaults / out of memory References: <87wrxb5p59.fsf@frosties.localdomain> <20100317083907.GC26002@janestreet.com> <87sk7zgtpq.fsf@frosties.localdomain> <87hboehphv.fsf_-_@frosties.localdomain> <874okd2907.fsf@frosties.localdomain> <53c655921003300014s2c7b05eax24b91edbb0d0d9ec@mail.gmail.com> In-Reply-To: <53c655921003300014s2c7b05eax24b91edbb0d0d9ec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; segfaults:01 ocaml:01 runtime:01 ocaml:01 runtime:01 pointer:01 allocates:01 functioning:98 caml-list:01 functions:01 functions:01 variables:02 variables:02 cached:02 slightly:03 > So, is it really forbidden to release the global lock in a noalloc function? Yes. Actually, it is forbidden to call any function of the OCaml runtime system from a noalloc function. Explanation: ocamlopt-generated code caches in registers some global variables of importance to the OCaml runtime system, such as the current allocation pointer. When calling a regular (no-"noalloc") C function from OCaml, these global variables are updated with the cached values so that everything goes well if the C function allocates, triggers a GC, or releases the global lock (enabling a context switch). This updating is skipped when the C function has been declared "noalloc" -- this is why calls to "noalloc" functions are slightly faster. The downside is that the runtime system is not in a functioning state while within a "noalloc" C function, and must therefore not be invoked. The cost of updating global variables is small, so "noalloc" makes sense only for short-running C functions (say, < 100 instructions) like those from the math library (sin, cos, etc). If the C function makes significant work (1000 instructions or more), just play it safe and don't declare it "noalloc". Hope this helps, - Xavier Leroy