[Gc] gc7 and 64-bit platforms
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
>> 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
> 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
> 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).
More information about the Gc