AIX

Greetings -

I'm porting a C application to an AIX (6.1) system, and have bumped into the limits AIX imposes on memory allocation, namely the default limit of 256MB for a process. I'm aware of the compilation flag that allows an application to gain access to up to 8 memory segments (each 256MB, for a total of 2GB) ... but that seems like an unnecessary restriction on a computer that offers more RAM than that.

A toy example I'm using is given here

Code:

int main(int argc, char *argv[]) {
  long long size = 2100000000;
  int *T = (int *)malloc (size);
  printf("alloc'd %ld : %d\n",size, T);
  free(T);
}

Compiling this without increasing segment count results in the malloc call returning a null pointer:

Code:

% /usr/vac/bin/xlc_r   -o hello hello.c
% ./hello 
alloc'd 2100000000 : 0

but adding the correct compile flag (for xlc) makes it work:

Code:

% /usr/vac/bin/xlc_r  -bmaxdata:0x80000000 -o hello hello.c
% ./hello 
alloc'd 2100000000 : 268486928

(note, malloc returns a null pointer even with this flag if I try to allocate 2200000000 bytes)

But I'm unable to figure out how to allow my program to use more memory than that. My impression is that in 64-bit mode, none of these memory restrictions should even be present, e.g.

(link omitted because I'm too new to this group ... but google will find it for you)

Which suggests to me that the first compilation above should've worked. Am I in 64-bit mode? I believe so:

Code:

% export OBJECT_MODE=64    
% /usr/vac/bin/xlc_r  -c hello.c  && file hello.o
hello.o: 64-bit XCOFF executable or object module not stripped

that's not what I see if I explicitly go for a 32-bit compile:

Code:

% /usr/vac/bin/xlc_r -q32 -c hello.c  && file hello.o
hello.o: executable (RISC System/6000) or object module not stripped

So ... what incredibly naive thing am I doing wrong? Any guidance is greatly appreciated.

(side note: I'm using xlc because it's required for the project. gcc isn't a viable option)

Thanks in advance.

-q64 : http://www.bluefern.canterbury.ac.nz...X/compiler.pdf

It's not just about RAM, it is about VM, like mmap64()!

Thanks for taking the time to reply. I failed to mention: I've compiled with -q64, resulting in no change to outcome.

I'll also observe that the manual you pointed me to says:
"Compiler mode is set according to the last-found instance of the -q32 or -q64
compiler options. If neither of these compiler options is set, the compiler mode
is set by the value of the OBJECT_MODE environment variable."

As mentioned in my original post, I set that with

Code:

export OBJECT_MODE=64

Is there something else I'm supposed to get from the manual?

It may ignore you if your platform or the specified target platform is not 64 bit address capable. However, it says it would warn.

The pdf says '=' after -bmaxdata, not ':'.

Does -qmaxmem= apply?

Are 64 bit libs in use/in dynamic search path?

Cute: setting compiler optimization space too big may exhaust swap!

Did you know that if you create a nominally huge ufs file with seek and write, only 1 block is used? Then, mmap6() allows you to do sparse array in 64 bit space, where missing entries are nulls for free (use RAM but no disk).

(Some sleazy money grubbers leave out options unless you buy a more premium compiler, so try gcc/g++ 64 bit and see if it works when this does not!)

Good luck!

please post the output of ulimit -a