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 garbage collector_S_
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-02-22 (21:41)
From: Kuba Ober <ober.14@o...>
Subject: Re: [Caml-list] ocaml garbage collector_S_
> industrial control process, audio processing share a need for others  
> pattern of allocation, solved using pools
> of memory range of various size.

I think that there is a big class of realtime signal processing where  
dynamic memory allocation is not only uncalled for, but would be a  
performance disaster. A good compiler for OCaml (or any other  
"dynamic" language) should be able to recognize where static  
allocation is applicable. Unfortunately, most compilers do not do  
whole-project compilation, they only deal with one file at a time.  
There is a large class of programs where memory can be completely  
statically allocated, and where you don't even need stack for anything  
but storage of function return addresses.

Some time ago I have done a rather bastardized and godawful Lisp  
compiler for eZ8 and SX microcontrollers, solely for use in realtime  
signal processing. Everything is type-inferred and statical types are  
assigned to all variables; there's no runtime polymorphism (the  
compiler barfs if any type would not be a constant after all type  
equations are derived and simplified). Even then, I can use many high- 
level constructs (currying, generic functions, functors) -- they end  
up having zero runtime overhead. The approach is perhaps similar to  
what ocamldefun would do, it's just taken one step further.

I posit that dynamic memory allocation and garbage collection are a  
secondary problem. The primary problem is doing code analysis at such  
a level that the amount of dynamic memory allocation is reduced only  
to places where it's inherently needed. Same goes for boxing: unless  
OCaml would do whole-program compilation, some boxing is inevitable in  
light of the compiler being unable to reason about all of the code.