Hello,
> To the extent that this rule is the same for all languages and that most
> languages on the shootout are also garbage collected, I think OCaml's
> problem with this benchmark do point at a weakness of the current
> GC code.
This is untrue ... the bintree example, is just bad in OCaml because the
default
value of the minor heap size is the correct value for reactive programs
where you want fast minor GC slice, because they interrupt the program ...

Maybe the Gc library could provide reasonable default settings for both
cases
accessible via a simple function GC.is_reactive : bool -> unit ... And
the shootout
would allow to call such a function ?

Clearly, all benchmarks which just measure speed and space should use a
larger
minor heap size (except if reactive communication between processes is
important in the
benchmark).

More importantly, there is little hope to discover at runtime that a
program is
a reactive one ... In other words there is no hope for a perfect GC for
all situations.
So it is a good thing that OCaml allows tuning the GC.

Moreover, even when you automatically tune the GC (like changing the
number of generations in some modern GC) you do it based on past
observation of the behavior of your program ... and the behavior of the
program can change just after you changed some GC parameters ... So
begin able to help the GC, in a comprehensive way,
is good ...

Cheers,
Christophe