Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Ocaml implementation and low level details
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-01-28 (21:16)
From: Konstantin Tcholokachvili <tcholoka@g...>
Subject: Re: [Caml-list] Ocaml implementation and low level details
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:
> Archives:
> Beginner's list:
> Bug reports: