[Gc] gc7 and 64-bit platforms

Peter Colson pcolson at connexus.net.au
Mon Nov 15 23:04:49 PST 2004

On 16/11/2004, at 5:03 PM, Hans Boehm wrote:

>> 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?

OK, this looks like a platform deficiency, sizeof(size_t) is definitely 
4. It's defined as an unsigned int.

> On Windows 64 size_t and ptrdiff_t are 64 bit values, as I would have
> expected.
> 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.

As a first cut I just wanted to see what happened running the uniq() 
part of gctest with gc7. To do this I finally hacked gc7 by global 
search-and-replacing all unsigneds, longs, size_t's, etc., as my own 
typedefs which I then ensured were long long's (thus equivalent to 
sizeof a pointer).

Unfortunately it bombed in exactly the same way as gc6.3 with the 
failure to mark from parameters. Again a platform deficiency that we're 
going to need to resolve (in the GC_push_regs area, I guess) before we 
can really progress any further (with either version).

Peter Colson.

More information about the Gc mailing list