ocaml garbage collector_S_

ocaml garbage collector_S_

[Philippe Strauss]

Hello ocaml'ers,

I've been long thinking about programming languages others than C, Perl, Python, the .Net family, java etc.
Anytime I discover a language come to mind a rather "niche" but interesting field: audio signal processing,
i.e. soft real time constraint and good numerical/overall performance.
Ocaml was not designed/targetted with such constraint in head (RT), but actually fit the bill not too badly with
a relatively simple and efficient GC, designed to be good at tasks functional prog. languages are used
to: lots of small sized values to allocate and free frequently.

industrial control process, audio processing share a need for others pattern of allocation, solved using pools
of memory range of various size.

Those 3 URL's point to a really interesting garbage collector project for real-time software,
using memory pools.
Initial versions of this project used "two level segregate fit" rather than pools and is still
available in later revision it seems:

http://www.notam02.no/index.php?/nor/Teknologi-og-tekst/Programvare/Audio-Rollendurchmesserzeitsammler
http://www.notam02.no/index.php?/nor/Teknologi-og-tekst/Programvare/Audio-Rollendurchmesserzeitsammler-Updates
http://archive.notam02.no/arkiv/src/?M=D

Remembering other needs like a concurrent GC and the multicore GC project of the OSP 2008, does the
idea of modifiying the GC of ocaml to make it a "pluggable" subsystem, with 3 runtimes you may choose from,
the "traditional" GC, the "real-time, pool based", and the "concurrent" one sounds reasonable?

Did this kind of need often pop-up in your mind?

-- 
Philippe Strauss
http://philou.ch

Re: [Caml-list] ocaml garbage collector_S_

[Jon Harrop]

On Sunday 22 February 2009 11:26:14 Philippe Strauss wrote:
> Remembering other needs like a concurrent GC and the multicore GC project
> of the OSP 2008, does the idea of modifiying the GC of ocaml to make it a
> "pluggable" subsystem, with 3 runtimes you may choose from, the
> "traditional" GC, the "real-time, pool based", and the "concurrent" one
> sounds reasonable?
>
> Did this kind of need often pop-up in your mind?

Yes, although I have been considering what might be done with OCaml's 
bytecode. Presumably it conveys all of the necessary information in a more GC 
agnostic way already. Moreover, a JIT compiler built upon LLVM could easily 
outperform the existing OCaml compilers.

You may be interested in these benchmark results I gathered for different VMs:

  http://flyingfrogblog.blogspot.com/2009/01/mono-22.html

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] ocaml garbage collector_S_

[Kuba Ober]

> 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