Re: [Caml-list] Ocaml implementation and low level details

[Goswin von Brederlow <goswin-v-b@web.de>]

Richard Jones <rich@annexia.org> 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