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
how to enlarge header of blocks?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-08-30 (11:16)
From: Mark Shinwell <Mark.Shinwell@c...>
Subject: Re: [Caml-list] how to enlarge header of blocks?
On Sat, Aug 27, 2005 at 01:17:40PM +0200, Christian Lindig wrote:
> >What information do you wish to store?  Rather than adjusting the block
> >headers, it might be possible to simply tack it onto the end as extra
> >fields, provided those fields obey the GC structure constraints.
> Currently I'd just like to store the address of the allocation site. 
> I've tried adding an extra field, hoping that the run-time system would 
> never access it. But either I did not get it right, or my assumptions 
> about the run-time system were too simple.

If the extra field obeys the GC structure constraints (see the Caml
documentation on interfacing to C) then you shouldn't have any
> As an alternative, one could maintain a table on the side that maps the 
> address of the block to whatever information is associated with it. But 
> since the garbage collector moves blocks, this isn't simple to 
> maintain, either.

Even if the GC were to correctly update the value pointers held in such
a table, such an approach would likely fail anyway as any such GC update
would break the invariants of the table (in particular if the value
pointers are acting as keys in a hashtable, where a change might mean
that values have to switch buckets).  There is the further difficulty
that registering many global memory roots should be avoided due to the
cost, which would affect the design of any such table.