Different behavior on ARM for --dynamic-space-size?

[cell]

While building a project which uses waf and sbcl as part of its build system, I noticed a difference in behavior:

On Linux X86_64 (and on Mac OS X), when I run `sbcl --dynamic-space-size xxx`, xxx can be larger than my physical memory + swap, which seems to be typical Linux overcommit behavior.

On Linux ARM, xxx has to be smaller than physical memory (and isn't affected by swap size) otherwise a call to mmap will fail.

I'm running Debian (stretch) on x86_64, and Raspbian (stretch) on a Raspberry Pi for ARM.

Is this difference a known behavior? I'm not even sure this is an sbcl issue -- maybe a Debian / Raspbian / kernel config issue?

Thanks

```
$ uname -a
Linux precision390 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
```

```
$ uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
```

[Stas Boukarev (stassats)]

./run-sbcl.sh --dynamic-space-size 3800
This is SBCL 1.4.15.81-7dbc076, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (machine-type)
"ARM"

It's your setup.

[cell (jasonpepas)]

Thanks, useful data point!

Can I ask which distro you are running on that arm box?

[cell (jasonpepas)]

I whipped up a simple mmap program:

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

int main(int argc, char** argv) {
    int fd = open(argv[1], O_RDONLY);
    if (fd == -1) {
        perror("open failed");
    }

    size_t sz = strtoll(argv[2], NULL, 10);
    if (sz == 0) {
        perror("strtoll failed");
    }

    char *mem = mmap(0, sz, PROT_READ, MAP_PRIVATE, fd, 0);
    if (mem == (void*)-1) {
        perror("mmap failed");
    }

    return 0;
}

it looks like the ARM machines have no problem with a large mmap call (100GB succeeds but 1TB fails):

root@zerow1:/tmp# gcc -Wall mmap.c
root@zerow1:/tmp# ./a.out a.out 1
root@zerow1:/tmp# ./a.out a.out 10
root@zerow1:/tmp# ./a.out a.out 100
root@zerow1:/tmp# ./a.out a.out 1000
root@zerow1:/tmp# ./a.out a.out 10000
root@zerow1:/tmp# ./a.out a.out 100000
root@zerow1:/tmp# ./a.out a.out 1000000
root@zerow1:/tmp# ./a.out a.out 10000000
root@zerow1:/tmp# ./a.out a.out 100000000
root@zerow1:/tmp# ./a.out a.out 1000000000
root@zerow1:/tmp# ./a.out a.out 10000000000
root@zerow1:/tmp# ./a.out a.out 100000000000
root@zerow1:/tmp# ./a.out a.out 1000000000000
mmap failed: Cannot allocate memory

on all of the machines I tested, none of them had problems with over-allocating via mmap.

So I'd guess the problem lies in how sbcl was compiled for Raspbian.

[Stas Boukarev (stassats)]

You can't map more than 4 GB on a 32-bit process.