Re: Memory limits?

I fiddled with the value of MAX_OOP_TABLE_SIZE and was able to get further through the original log file but I hit another barrier at about 2GB, which may be the int limitation as int is signed.

I redid the code slightly to try in Squeak and it worked fine, actually taking up less memory for the whole file whereas I was hitting the limits on gst at about the halfway mark. It was faster too but I hadn't tried the jit in gst so the comparison doesn't mean much.

I confirmed that an int was 4-bytes here too, BTW.

Thanks for the help.

Thomas


[email protected] writes:

>> The reason I asked is because a 1GB limit could point towards some 32bit
>> limitation, just a guess.
>
> Inspection of the source code shows some use of 'int' type.
>
> The 'int' type is 4 bytes, even in 64 bit executables whereas 'long' can be 8 bytes or 4 bytes,
> depending on compiled in 32bit or 64bit mode.
>
> So the use of the 'int' type may impose in some cases some kind of 32bit limitations;
> it is an indirect limitation as the counter refers to the number of objects, not to the actual memory size.
>
> So basically what you have to find out is whether anyone is using GNU st in 64 mode with large numbers of objects.
>
> It is perhaps not so difficult after all to remove those usages of 'int' and the resulting limitations.
>
> Also there is (almost non-existing) possibility that it is different on your platform, but extremely unlikely:
>
> $ cc -m32 sizeofint.c
> $ ./a.out
> sizeof(int) is 4
>
> $ cc -m64 sizeofint.c
> $ ./a.out
> sizeof(int) is 4
>
> $ cat sizeofint.c
>
> #include <stdio.h>
>
> int main(int argc,char *argv[])
> {
>   int i = 1 << 23;
>
>   printf("sizeof(int) is %d\n",sizeof(int));
> }