[Gc] gc7 and 64-bit platforms

Hans Boehm Hans.Boehm at hp.com
Mon Nov 15 22:03:38 PST 2004

On Tue, 16 Nov 2004, Peter Colson wrote:

> I've been looking at gc7 and am wondering if it's at least LP64
> compliant (obviously it's not LLP64-compliant at this stage)?
My primary machine is an Itanium 2 machine running Linux, which
is LP64.  That should be fine.
> I see instances where a word var is assigned to an int (dbg_mlc,
> GC_generate_random_heap_address(), line 148). Now if sizeof(int) <
> sizeof(long) and sizeof(word) == 8 this will be a problem on either
> style of 64-bit platform.
That's a stylistic error.  I think both values should be size_t.
I don't think an overflow is actually possible there, but I'll fix it.

> Also, possibly more widespread, interchanging size_t and word usage
> (allchblk, GC_allocchblk and GC_allocchblk_nth sz param,  and
> elsewhere). On an LP64 platform do you imagine that size_t would be
> promoted to an 8-byte size as per long? On my LLP64 platform size_t
> remains at 4 bytes (unsigned long) while word becomes 8-bytes (unsigned
> long long)? So is this interchange of word and size_t vars valid?
So this is a 64-bit platform on which you can't map a 6GB file?
Otherwise you end up with a single object whose length doesn't fit in
a size_t?  Or how do they make this work?

On Windows 64 size_t and ptrdiff_t are 64 bit values, as I would have

Aside from the fact that this feels wrong to me, we can probably still
make this work.  I'm trying to use size_t only for things that are either
object sizes, or the length of memory regions allocated from the OS, or
the like.  If the OS refuses to allocate anything bigger than 4GB,
then this should mostly work.  There may be some boundary conditions
if you allocate just under 4GB that I didn't anticipate.


More information about the Gc mailing list