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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 290D5BF2D for ; Thu, 31 Aug 2006 23:08:28 +0200 (CEST) Received: from mtaout-a.tc.umn.edu (mtaout-a.tc.umn.edu [134.84.119.206]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7VL8RIL003176 for ; Thu, 31 Aug 2006 23:08:27 +0200 Received: from [128.101.106.92] (glu02.cs.umn.edu [128.101.106.92]) by mtaout-a.tc.umn.edu with ESMTP for caml-list@yquem.inria.fr; Thu, 31 Aug 2006 16:08:24 -0500 (CDT) X-Umn-Remote-Mta: [N] glu02.cs.umn.edu [128.101.106.92] #+LO+TS+AU+HN Message-ID: <44F74FC7.909@cs.umn.edu> Date: Thu, 31 Aug 2006 16:08:23 -0500 From: Christopher Kauffman User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OCaml Subject: Re: [Caml-list] Garbage collection and caml_adjust_gc_speed - Problem in Bigarray References: <44F3BFA7.20202@cs.umn.edu> <8B65BEE5-D101-4B39-98DD-3B68608702AC@inria.fr> <44F48960.6080908@cs.umn.edu> <44F7018A.7040905@cs.umn.edu> In-Reply-To: <44F7018A.7040905@cs.umn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44F74FCB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bigarray:01 shivkumar:01 bigarray:01 arrays:01 lacaml:01 ocaml-:01 otherlibs:01 stubs:01 alloc:01 alloc:01 cheers:01 shivkumar:01 garbage:01 garbage:01 caml-list:01 After some very helpful advice from Shivkumar Chandrasekaran, I have located the source of the problem. In my code, a very frequent operation is to take a slice of a matrix or array (a column of a matrix representing the X-coordinates of some atoms for instance) and perform some operations on that slice. This is supported in the Bigarray library with the 'slice_left' function (for fortran_layout arrays) and in Lacaml with Mat.col function. Unfortunately, using this operation results in the following sequence of underlying C-function calls in ocaml-3.09.2/otherlibs/bigarray/bigarray_stubs.c: bigarray_slice() -> alloc_bigarray() -> alloc_custom() -> caml_adjust_gc_speed() So even though there is no allocation of new underlying data, taking a slice creates custom data to manage the new alias which triggers GC adjustment. I am certainly not familiar with the inner workings of the garbage collector, but this seems like undesirable behavior as much efficiency is lost for no apparent reason. This now seems like an issue with the Bigarray library. Please advise me on the protocol for submitting this issue that it might be considered for correction in a future release. Cheers, Chris PS - Thanks again to Shivkumar!