Re: [Caml-list] ocaml garbage collector_S_

[Kuba Ober <ober.14@osu.edu>]

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

Kuba