[Gc] gc on 64-bit machines
pcolson at connexus.net.au
Thu Oct 28 19:15:13 PDT 2004
On 29/10/2004, at 5:26 AM, Boehm, Hans wrote:
>> From: Peter Colson [mailto:pcolson at Connexus.net.au]
>> On 28/10/2004, at 4:30 AM, Boehm, Hans wrote:
>>> Unfortunately, I expect this problem is quite widespread.
>>> I consider these casts to be a bug, and have so for quite
>>> a while. But the collector has never been tested on an
>>> LLP64 platform (i.e. Windows 64, I presume; I know of no
>> Platform is AS/400 using ILE/C with teraspace options. I'm going to
>> look for compile options that may be able to make it LP64, but am not
> Interesting. I had thought that only Microsoft had gone that route.
Yes, the DTAMDL(*LLP64) compiler option pretty much says it all.
>> What would be your estimate of effort to fix all instances of cast to
>> long so that they cast to word?
> I did a grep for (long). It mostly doesn't look too bad. The most
> problem in terms of code changes is the GC_printf stuff, which uses
> unsigned long or long arguments everywhere, and is spread through the
> tree. It is fixed in my gc7 tree, but not in gc6.*. It may just break
> not the collector itself.
> Aside from the GC_printf stuff, I think it would take me about two
> hours to
> make the changes, and anywhere between a day (less if we get really
> and several weeks to debug the result. That presumes familiarity with
> collector debugging. It's always very variable, since it depends
> on the number of intermittent bugs that show up.
With the testing that you do, is that something we could help with on
the 400 to assist you? The sooner we can get a gc operating in that
environment, the better for us.
Furthermore, if you have testing tools that you typically use that may
be of use on this platform it might come in handy because I still think
there are other portability issues. I'm using GC_find_limit to
initialise DATASTART/DATAEND, using a dummy static (rather than
'_end') - this is probably wrong, but at least got us compiling.
Also we don't use dll's or shared libs, but 'service programs' that
live in their own process so there could be issues in dyn_load.c.
So any testing we can do to confirm correct operation helps us (as well
as confirming correctness of the gc in a LLP64 environ).
> It's more likely to be
> on the low end of the scale if you don't need thread support.
The system using the gc is threaded (pthreads or win32 threads
supported) so I assume this means it is using the gc in threaded mode.
More information about the Gc