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)); > }
