[Beowulf] Quick question... on Fortran

[Mark Hahn]

> The gross 32-bit layout, from bottom to top is: program & data, shared libs &
> mmap, heap, and stack; with the space between the code/data and shared libs
> controlled by brk(2).

let me offer a brief program and a few more details (not in disagreement):
#include <stdio.h>
#include <stdlib.h>

char static_variable;

int main() {
     char auto_variable;
     char *heap_variable = malloc(1);
     FILE *fp;
     char buf[1000];
     printf("static variable at %p\n",&static_variable);
     printf("auto   variable at %p\n",&auto_variable);
     printf("heap   variable at %p\n",heap_variable);
     fp = fopen("/proc/self/maps","r");
     while (fgets(buf,sizeof(buf),fp)) {
         write(1,buf,strlen(buf));
     }
     return 0;
}

on older ia32 linux systems:

[hahn at old-cat hahn]$ ./showmemory 
static variable at 0x80496cc
auto   variable at 0xbfffd92f
heap   variable at 0x80496d8
08048000-08049000 r-xp 00000000 09:00 65734      /home/hahn/showmemory
08049000-0804a000 rw-p 00000000 09:00 65734      /home/hahn/showmemory
0804a000-0804b000 rwxp 00000000 00:00 0 
40000000-40012000 r-xp 00000000 08:01 208561     /lib/ld-2.2.93.so
40012000-40013000 rw-p 00012000 08:01 208561     /lib/ld-2.2.93.so
40013000-40015000 rw-p 00000000 00:00 0 
40019000-4001a000 rw-p 00000000 00:00 0 
42000000-42126000 r-xp 00000000 08:01 128278     /lib/i686/libc-2.2.93.so
42126000-4212b000 rw-p 00126000 08:01 128278     /lib/i686/libc-2.2.93.so
4212b000-4212f000 rw-p 00000000 00:00 0 
bfffc000-c0000000 rwxp ffffd000 00:00 0

so, 128M of zero-page, text, static/bss, heap growing up towards mmap arena
starting at 1G, with stack starting at 3G growing down.  so the largest 
single brk-available space was ~896M.  glibc malloc, however, will use mmap
for large allocations so can give you nearly 2G beneath the stack.

interestingly, modern ia32 (this is centos 4) look like this:
static variable at 0x80497b0
auto   variable at 0xbff4348f
heap   variable at 0x8ac0008
00287000-0029c000 r-xp 00000000 03:03 35888      /lib/ld-2.3.4.so
0029c000-0029d000 r-xp 00015000 03:03 35888      /lib/ld-2.3.4.so
0029d000-0029e000 rwxp 00016000 03:03 35888      /lib/ld-2.3.4.so
002a5000-003ca000 r-xp 00000000 03:03 35889      /lib/tls/libc-2.3.4.so
003ca000-003cc000 r-xp 00124000 03:03 35889      /lib/tls/libc-2.3.4.so
003cc000-003ce000 rwxp 00126000 03:03 35889      /lib/tls/libc-2.3.4.so
003ce000-003d0000 rwxp 003ce000 00:00 0 
08048000-08049000 r-xp 00000000 03:03 4637246    /home/hahn/showmemory
08049000-0804a000 rw-p 00000000 03:03 4637246    /home/hahn/showmemory
08ac0000-08ae1000 rw-p 08ac0000 00:00 0 
b7f78000-b7f79000 rw-p b7f78000 00:00 0 
b7f89000-b7f8b000 rw-p b7f89000 00:00 0 
bff42000-c0000000 rw-p bff42000 00:00 0 
ffffe000-fffff000 ---p 00000000 00:00 0

putting those "standard" mmaps under 128M is a pretty nice tweak, since 
without any heroics (static compilation, etc) , an unbroken 2.8G are available.

on x86_64, I see:
static variable at 0x500bac
auto   variable at 0x7fbfffe860
heap   variable at 0x501010
00400000-00401000 r-xp 00000000 00:15 17813231                           /home/hahn/showmemory
00500000-00501000 rw-p 00000000 00:15 17813231                           /home/hahn/showmemory
00501000-00522000 rwxp 00501000 00:00 0 
2a95556000-2a95559000 rw-p 2a95556000 00:00 0 
2a95579000-2a9557a000 r-xp 00000000 08:05 682971                         /hptc_cluster/sharcnet/opt/pathscale/pathscale-2.2.1/lib/2.2.1/libpscrt.so.1
2a9557a000-2a95679000 ---p 00001000 08:05 682971                         /hptc_cluster/sharcnet/opt/pathscale/pathscale-2.2.1/lib/2.2.1/libpscrt.so.1
2a95679000-2a9567a000 rw-p 00000000 08:05 682971                         /hptc_cluster/sharcnet/opt/pathscale/pathscale-2.2.1/lib/2.2.1/libpscrt.so.1
2a9567a000-2a9567c000 rw-p 2a9567a000 00:00 0 
383e200000-383e215000 r-xp 00000000 08:02 4235194                        /lib64/ld-2.3.4.so
383e314000-383e316000 rw-p 00014000 08:02 4235194                        /lib64/ld-2.3.4.so
383e600000-383e72a000 r-xp 00000000 08:02 4235196                        /lib64/tls/libc-2.3.4.so
383e72a000-383e82a000 ---p 0012a000 08:02 4235196                        /lib64/tls/libc-2.3.4.so
383e82a000-383e82d000 r--p 0012a000 08:02 4235196                        /lib64/tls/libc-2.3.4.so
383e82d000-383e830000 rw-p 0012d000 08:02 4235196                        /lib64/tls/libc-2.3.4.so
383e830000-383e834000 rw-p 383e830000 00:00 0 
7fbfffd000-7fbffff000 rwxp 7fbfffd000 00:00 0 
7fbffff000-7fc0000000 rw-p 7fbffff000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0

which is similar in order to old ia32.  note that a 32b program on a x86_64 kernel
_will_ actually see a full 4G address space, so ~3.8G between mmap arena and stack.

regards, mark.