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 TAA15827; Mon, 31 Dec 2001 19:02:05 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA15735 for ; Mon, 31 Dec 2001 19:02:04 +0100 (MET) Received: from web10702.mail.yahoo.com (web10702.mail.yahoo.com [216.136.130.210]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id fBVI22H15512 for ; Mon, 31 Dec 2001 19:02:03 +0100 (MET) Message-ID: <20011231180201.43925.qmail@web10702.mail.yahoo.com> Received: from [209.179.218.223] by web10702.mail.yahoo.com via HTTP; Mon, 31 Dec 2001 10:02:01 PST Date: Mon, 31 Dec 2001 10:02:01 -0800 (PST) From: Shannon --jj Behrens Subject: Re: [Caml-list] Kernel in OCAML using native compiler To: caml-list@inria.fr In-Reply-To: <15408.41633.311678.235219@hector.lesours> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Read a good book on Garbage Collection (for instance > Lins') and you'll > find out that reference counting is the worst GC > technique (except for > some cases of distributed GC). It performs poorly > and don't handle > cycles. Ok, thank you for explaining this to me. > Ocaml's GC is one of the best and is tunable. It is > generational, > copying for the minor collection, and incrementally > mark&sweep for the > major collection. For application development, it is quite nice. > Even if you did happen to put a refcounting GC > (which means rewriting > Ocaml runtime and significant part of the compiler) > you'll probably > get worse performance. In terms of overall time spent doing GC, I'm sure you're right. However, I imagine that there are other algorithms that may provide lower latency (i.e. shorter pauses caused by GC). In providing GC for a kernel, short latency is required, even if the GC will eventually take twice as much time. > Generally, using dynamic memory is perhaps not the > best idea for a > very low level kernel routine. Perhaps. However, I feel that there are some parts of the kernel that could really benefit from GC. In specific, I'd really like to get rid of as many limits as possible. For instance, the number of processes in Minix is fixed (requiring a recompile) because the process table is not created dynamically. If some kernel level malloc were available, the process table could grow as needed. I understant that this is not an "easy" problem. > You should describe what are you wanting to > implement in Ocaml inside > a kernel. Well, actually, my goal is to write a minimalistic kernel almost entirely in a high level language like OCAML. It appears that many of my goals are the same as the tunes project you mentioned (which I'm currently reading through)--especially reflection (as you mentioned). By the way, your first email to me mentioned the GC issue, and despite three readings, it didn't sink in until I starting doing those tests. I apologize that you had to repeat yourself ;) Well, I'll keep learning. Thanks for your patience. -jj __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr