From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id B2F45BC37 for ; Thu, 28 Jan 2010 21:22:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApICAAiBYUvZSMDji2dsb2JhbACBNJoWAQEBCgsKBxEFvSCEPAQ X-IronPort-AV: E=Sophos;i="4.49,362,1262559600"; d="scan'208";a="50470430" Received: from fmmailgate02.web.de ([217.72.192.227]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Jan 2010 21:22:57 +0100 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id E3E3514CC200E for ; Thu, 28 Jan 2010 21:22:56 +0100 (CET) Received: from [95.208.117.111] (helo=frosties.localdomain) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1Naat7-0004QT-00 for caml-list@yquem.inria.fr; Thu, 28 Jan 2010 21:22:49 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1Naat3-00019i-TB for caml-list@yquem.inria.fr; Thu, 28 Jan 2010 21:22:45 +0100 From: Goswin von Brederlow To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ocaml implementation and low level details References: <20100128183950.GA7701@annexia.org> Date: Thu, 28 Jan 2010 21:22:45 +0100 In-Reply-To: <20100128183950.GA7701@annexia.org> (Richard Jones's message of "Thu, 28 Jan 2010 18:39:50 +0000") Message-ID: <878wbim12i.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX19VJaAlrDqGsiQ3WBRx9Y64EOrhxfsvq5quowN/ iGUDcHNHRBmBjHqHUWXCca8znD0583nbVZ//weIXFb4XyZyZ0u R9Pd0X5qY= X-Spam: no; 0.00; ocaml:01 0100,:01 ocaml:01 ocaml's:01 runtime:01 runtime:01 subset:01 mutables:01 recursive:01 datatypes:01 compiler:01 28,:98 interrupts:98 mfg:98 garbage:01 Richard Jones writes: > On Thu, Jan 28, 2010 at 01:42:15PM +0100, Konstantin Tcholokachvili wrote: >> I am writing an operating system kernel and I am considering the idea of >> rewritting it in Ocaml or make a wrapper. >> As I don't know how Ocaml is implemented in detail so I have the following >> question: >> If want to code in Ocaml without using the garbage collector, will I be able >> to use my own multithreading implementation or will I be limited by Ocaml's >> global lock? > > You're probably better off not using the current runtime, but instead > implementing enough of the runtime based on the functions that the > code generator needs. But reading the rest of the thread it sounds > like you really need to look deeply at the current implementation > first before you are in a position to make any decision (luckily the > runtime of OCaml is not hard to understand, and is mostly written in > C). Asking if one can code in OCaml "without using the garbage > collector" doesn't really make any sense as a question, since at least > the minor heap is a fundamental concept in the language. And the > "global lock" just prevents reentrancy in the current implementation > of the GC -- you can easily use one minor heap per thread, although > that is likely to just push the problem elsewhere. > > Rich. A heap per thread makes inter thread communication more difficult. On the other hand it allows multi core support and keeps the GC work per thread small. Still, you can't have interrupts that allocate memory while the GC runs and such. So you need at least some part that is outside the GC. I've played with the idea of using ocaml (or variant thereof) for a kernel too. My idea was to write a minimal mikrokernel in a restricted subset of ocaml and then allow ocaml with GC for the drivers and modules. Each driver/module would be a seperate process with its own stack and heap and use little memory. So the GC work wouldn't mean long interruptions even if compacting. For the core I was thinking that maybe one could cut out heap alocation and instead use stack allocation with some manual allocation for special cases for the core. That would mean a number of changes though: - use in-place algorithms (mutables) for a lot of things - no deep recursive datatypes as return values - allocate the maximum size for variant types for returns - allocate space for the return value on the caller stack No heap allocation means no GC required. On the other hand a stack value must never escape the function it is allocated in. Tracking that would be a huge change in the compiler. Overall I was afraid the result would be more changed things than remaining ocaml. So it never wnet further than some thought epxperiments. But maybe this gives someone some ideas. MfG Goswin