История изменений

Это рост адресного пространства, а не выделение памяти.

Ну так нельзя в таком великонаучном споре опускаться в такую вульгарщину. Адресное пространство определяется битностью. Царь, слаще 286 и 386 не видевший, может вам даже расскажет, что раз на x86 больше 3G на процесс просто так не получишь, то это и есть Велика Реальность 32-битности. :)

При запросе sbrk/mmap(dev/zero|anon) происходит рост разрешённых ОС для доступа конкретному процессу границы виртуального пространства или страниц виртуального пространства соответственно. Можно получить доступ к реальной памяти, например к видеобуферу, это когда-то даже делалось типа так: map=ioctl(0,MAPVGA,0); на SCO/MS Xenix, да даже mmap к физическому файлу не «расширяет адресное пространство», а опеределяет, что вот этот кусок пространства теперь связан с.

Поведение ядра спорное, но, увы, сейчас считается нормальным.

Вполне возможно это такое «не мытьём, так катанием» продвижение изменения, чтобы наконец дошло, что стандарты со времен 64k/процесс поменялись, и пора сделать malloc_spare() ? То есть дополнительный флаг у mmap? Пока без этого флага — работаем с имеющейся памятью: физика+своп, убиваться по доступу к ранее неинициализированной памяти — нельзя. Хотите дырявую память — так пожалуйста, юзайте вот этот spare и будьте готовы, что при первом обращении к памяти, выделенной именно этим методом можете в любой момент подохнуть. Делать ли такой malloc_spare псевдонимом к malloc будет определяться дистрибутивом :)

Пока же имеем «настройку» vm для всей системы целиком и malloc_spare=malloc и живём с этим :(

Это рост адресного пространства, а не выделение памяти.

Ну так нельзя в таком великонаучном споре опускаться в такую вульгарщину. Адресное пространство определяется битностью. Царь, слаще 286 и 386 не видевший, может вам даже расскажет, что раз на x86 больше 3G на процесс просто так не получишь, то это и есть Велика Реальность 32-битности. :)

При запросе sbrk/mmap(dev/zero|anon) происходит рост разрешённых ОС для доступа конкретному процессу границы виртуального пространства или страниц виртуального пространства соответственно. Можно получить доступ к реальной памяти, например к видеобуферу, это когда-то даже делалось типа так: map=ioctl(0,MAPVGA,0); на SCO/MS Xenix, да даже mmap к физическому файлу не «расширяет адресное пространство», а опеределяет, что вот этот кусок пространства теперь связан с.

Поведение ядра спорное, но, увы, сейчас считается нормальным.

Вполне возможно это такое «не мытьём, так катанием» продвижение изменения, чтобы наконец дошло, что стандарты со времен 64k/процесс поменялись, и пора сделать malloc_spare() ? То есть дополнительный флаг у mmap? Пока без этого флага — работаем с имеющейся памятью: физика+своп, убиваться по доступу к ранее неинициализированной памяти — нельзя. Хотите дырявую память — так пожалуйста, юзайте вот этот spare и будьте готовы, что при первом обращении к памяти, выделенной именно этим методом можете в любой момент подохнуть. Делать ли такой malloc_spare псевдонимом к malloc будет определяться дистрибутивом :)