From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA24432; Tue, 20 Apr 2004 02:31:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA24118 for ; Tue, 20 Apr 2004 02:31:57 +0200 (MET DST) Received: from woodstock.1969.ws (64-215-156-42.eosinc.net [64.215.156.42]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i3K0VtYM025291 for ; Tue, 20 Apr 2004 02:31:55 +0200 Received: (qmail 6306 invoked from network); 20 Apr 2004 00:30:07 -0000 Received: from karl.1969.ws (HELO 1969.ws) (10.3.2.15) by woodstock.1969.ws with SMTP; 20 Apr 2004 00:30:07 -0000 Message-ID: <40846F57.9000201@1969.ws> Date: Mon, 19 Apr 2004 17:31:19 -0700 From: Karl Zilles Organization: 1969 Communications, Inc. User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Hurt CC: Basile Starynkevitch , Ocaml Mailing List Subject: Re: [Caml-list] Real Time Ocaml References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 allocations:01 ocaml:01 ocaml:01 garbage:01 garbage:01 collector:02 collector:02 wrote:03 allocate:03 horrible:04 realtime:05 realtime:05 brian:06 memory:09 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Brian Hurt wrote: > The only thing non-realtime in Ocaml is the garbage collection. There are > realtime garbage collectors, which do a certain amount of work every > allocation, so that a) the cost of every allocation is constant (or close > enough), and b) that all the work the collector ever needs to do is > distributed evenly among the allocations. The current collector, while > perfect for non-realtime tasks (due to it's small average cost) is > horrible for realtime because of the huge difference between the common > case (5 instructions) and the worst case (mass collection)> In a realtime garbage collector, how can you prove that you are freeing unused memory as fast as you allocate it? In your attempt to put a boundry on time, doesn't it open up the possiblility that you might run out of space (even if your program has constant memory usage). ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners