From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA15546 for caml-redistribution; Mon, 13 Dec 1999 12:41:30 +0100 (MET) 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 AAA11291 for ; Mon, 13 Dec 1999 00:57:41 +0100 (MET) Received: from ruby (kyle16.zip.com.au [61.8.17.144]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id AAA29229 for ; Mon, 13 Dec 1999 00:57:32 +0100 (MET) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id KAA05447 for ; Mon, 13 Dec 1999 10:59:01 +1100 Sender: weis Message-ID: <385436C4.586B2D0A@maxtal.com.au> Date: Mon, 13 Dec 1999 10:59:00 +1100 From: skaller Organization: Maxtal X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Gc Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How does (or should I say 'can') the garbage collector tell the difference between a pointer to a structured block, and a pointer to something else (outside the caml heap)? I knew that the low bit of a value was used to distinguish pointers from integers. I assumed that the bit was set (1) for pointers to structured blocks (and had to be masked out before dereferencing), and unset (0) for integers (requiring a right shift to extract the integers). This would allow word aligned arbitrary 'foreign' pointers to be used without special handling (because they just look like ubboxed things to the collector) To my surprise, it works the other way. Clearly, this makes dereferencing pointers more efficient, but it makes it impossible to use foreign pointers as values -- unless the collector 'knows' where all structure blocks live and tests for that. [Conservative collectors often do just that] Is this the case?? ----------------------------------- By the way, this: #if SIZEOF_INT == 4 typedef int int32; typedef unsigned int uint32; #elif SIZEOF_LONG == 4 typedef long int32; typedef unsigned long uint32; #elif SIZEOF_SHORT == 4 typedef short int32; typedef unsigned short uint32; #endif from mlvalues.h is a really bad idea. The names int32, uint32, etc are commmonly used by OTHER header files. It is, unfortunately, better practice to use a name like: caml_int32 just to avoid a conflict. [For example, if some other head file contains: #define int32 int then the caml header will be equivalent to typedef int int; which is invalid syntax] [The same applies to the header file named 'config.h', this name is common, and prevents moving the caml header files into a directory shared by others: 'caml_config.h' is a better name] -- John Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller voice: 61-2-9660-0850