English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] local root registration
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-02-22 (12:00)
From: Winfried Dreckmann <wd@l...>
Subject: [Caml-list] local root registration
Dear Caml-list,

Some time ago, Xavier Leroy wrote:

> We've been through several designs for the "local root registration" API.
> The CAMLxxx macros are the latest design, and the one that we think is
> the easiest to use.

I agree that they are easiest if one strictly follows the rules in the
documentation. However, I would like to point out that there are cases where
one does not want to do this. In these cases, the older macros (Begin_roots
and End_roots) are much more flexible, and can even lead to better code.

I will discuss this a little. Perhaps the Begin_roots/End_roots macros
should not be deprecated, but left as a low level alternative? In one case
the documentation already differs between a simple and a low level
interface, and I believe this is a good approach. What do other list members

I am thinking of cases, where one uses resizable blocks, which are only
occasionally resized, while usually nothing gets allocated. A good example
is Michel Quercia's "Numerix". He has resizable big integers, and of course
wants to save every cpu cycle for crucial arithmetic operations when
allocation does not occur. His approach is to surround the allocators and
resizers by Begin_roots/End_roots macros, e. g.

#define Enlarge_1_1(a,l,b) {             \
  if (Capacity(a) < (l)) {               \
    Begin_roots2(a,b);                   \
    New(a,0,2*(l)+1);                    \
    End_roots2(a,b);                     \
  }                                      \

(see "lib/common/ml-alloc.h" in the numerix distribution). In this way, the
price for garbage collection is only paid if allocation actually takes
place. It seems impossible to achieve the same effect with CAMLxxx macros.

Winfried Dreckmann

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners