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

[Konstantin Tcholokachvili <tcholoka@gmail.com>]

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 <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
>
> _______________________________________________
> 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
>