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 89E39BC37 for ; Thu, 28 Jan 2010 22:16:19 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUBANeNYUtKfU4ZkGdsb2JhbACPOIIHiU09AQEBAQkJDAcTA60sgUWFKohmAQEDBYQ4BA X-IronPort-AV: E=Sophos;i="4.49,363,1262559600"; d="scan'208";a="50472687" Received: from ey-out-2122.google.com ([74.125.78.25]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Jan 2010 22:16:19 +0100 Received: by ey-out-2122.google.com with SMTP id d26so297881eyd.31 for ; Thu, 28 Jan 2010 13:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=V4FQkoU7MMOX8vpsSQT3hTLFf1FxeQ/Rz5LrEqjQFAA=; b=DSK8NL3blnu1uESoozBxLS04Bl4HXoFCTvBa1+OX5ztbyutHDZ/C5RUyiPyzBB7rOA nYG/c1bgYVkA8h0vQ6p2Q9sg0r6XZN6UR07bHlEOOQSuhgWkbcr5kxE/hRgrqgKk/IUi A4fxkEk6xfdPUzje1RlXgZeNSQ+Rcu5aPPjdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f1QqJM7zAiEbInLmDutZd6gbcOSNPT3ptSvOHIlKJeEHxGH8Irj5kNbN91iO0SymqX nhWnU0pmYPiqMT0L5jKgWSez8SEqRT9xN4j4pN9e49Oj6cHHwKD9CGcKVm/ZB6TJIYO1 2be2dKdmLsXgalfGgtpwISqPgGo1Yx3qnSyWA= MIME-Version: 1.0 Received: by 10.213.46.82 with SMTP id i18mr2989089ebf.50.1264713378807; Thu, 28 Jan 2010 13:16:18 -0800 (PST) In-Reply-To: <878wbim12i.fsf@frosties.localdomain> References: <20100128183950.GA7701@annexia.org> <878wbim12i.fsf@frosties.localdomain> Date: Thu, 28 Jan 2010 22:16:18 +0100 Message-ID: Subject: Re: [Caml-list] Ocaml implementation and low level details From: Konstantin Tcholokachvili To: Goswin von Brederlow Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 ocaml:01 inference:01 jocaml:01 0100,:01 ocaml's:01 runtime:01 runtime:01 subset:01 mutables:01 recursive:01 datatypes:01 compiler:01 beginner's:01 bug:01 Thank for all your replies, after reading different messages, it seems that D language fits most of my needs/taste unless I find another ML based language suitable for kernel coding. The thing I like about Ocaml is it's ability of type inference and it's speed, that's why I considered it. I guess that as JoCaml is based on Ocaml it has the same issues for kernel coding. Konstantin Tcholokachvili 2010/1/28, Goswin von Brederlow : > 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 > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >