From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 52452BDCB for ; Tue, 30 Aug 2005 13:16:26 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7UBGP1P010309 for ; Tue, 30 Aug 2005 13:16:25 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA15808 for ; Tue, 30 Aug 2005 13:16:25 +0200 (MET DST) Received: from copper.three-tuns.net (copper.three-tuns.net [193.201.200.235]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7UBGODb010304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 30 Aug 2005 13:16:25 +0200 Received: from mark by copper.three-tuns.net with local (Exim 4.52) id 1EA46K-0002e8-G4; Tue, 30 Aug 2005 12:16:24 +0100 Date: Tue, 30 Aug 2005 12:16:24 +0100 From: Mark Shinwell To: Christian Lindig Cc: Caml List Subject: Re: [Caml-list] how to enlarge header of blocks? Message-ID: <20050830111624.GC5470@three-tuns.net> References: <34f22df101c14e15560de909ace48d3a@cs.uni-sb.de> <20050826113400.GB5470@three-tuns.net> <6a0d230d1d1dd537d5c33ff693437c84@cs.uni-sb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a0d230d1d1dd537d5c33ff693437c84@cs.uni-sb.de> User-Agent: Mutt/1.5.9i Sender: Mark Shinwell X-Miltered: at nez-perce with ID 43144009.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43144008.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; shinwell:01 shinwell:01 caml-list:01 lindig:01 run-time:01 run-time:01 interfacing:01 garbage:01 pointers:01 invariants:01 pointers:01 hashtable:01 avoided:01 ...:98 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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 problem... > 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. Mark