Gc Question

[skaller <skaller@maxtal.com.au>]

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