Что такое аппаратный стек

[realeugene]

Munin в сообщении #1316283 писал(а):

Ещё "сегмент стека" (поскольку размер самого стека величина переменная).

Про сегменты на x86 больше не вспоминают уже примерно четверть века, со времени перехода на плоскую 32-битную модель адресного пространства процесса. Почти не вспоминают, кроме самых глубин реализации ядра и некоторых тонкостей реализации TLS. Ресайзинг стека прекрасно делается средствами виртуальной адресации и резервированием некоторого максимального размера адресного пространства под стек.

[Munin]

Вот только почему-то из объектных и исполняемых файлов они никуда не исчезли.

[realeugene]

Вы с секциями объектников не путаете? В объектниках префиксы сегментов упоминаются как детали реализации TLS и исключений C++. Основное адресное пространство процесса, в том числе, содержащее стеки нитей, единое и плоское. Все основные сегментные регистры при этом содержат одинаковые значения. Это удобно, так как адрес объекта в памяти является 32-битным числом и не содержит номера сегмента (64-битным в новых системах).

[iakovk]

Qlin в сообщении #1316167 писал(а):

Изложу свои догадки, пусть кто-нибудь меня поправит. Как я понимаю, аппаратным стеком может служить абсолютно любая часть оперативной памяти. Физически он никак не выделен, существует столько, сколько выполняется программа. ОС выделяет по одному стеку на каждую выполняемую программу. Все верно?

Почти.
(Все, что я дальше буду говорить, касается ОС Windows и соответственно архитектуры x86. О других вариантах пусть говорят другие).
По всей видимости, говоря "аппаратный стек", топикстартер имеет в виду ту структуру данных, для работы с которой в архитектуре x86 существуют специальные инструкции.
Если так, то да, для стека может быть выделена любая область памяти - по усмотрению операционной системы. ОС выделяет, строго говоря, по два стека каждому потоку - стек режима пользователя и стек режима ядра. Программа может быть многопоточной, у каждого потока свой стек. Все дальнейшее - только про стек режима пользователя.

Qlin в сообщении #1316167 писал(а):

Но я не понимаю, почему ограничение в 1 Мб не срабатывает.

Как было сказано выше, 1MB - это всего лишь значение по умолчанию. Оно прописывается в заголовке исполняемого файла и может быть изменено параметром /STACK компоновщика. Подробности - тут.
Когда программа исчерпывает выделенную область и хочет получить еще, возникает страничный отказ. Диспетчер памяти его обрабатывает и выделяет еще памяти - если есть. Если нету, программа получает исключение с кодом STATUS_STACK_OVERFLOW.
В вашем случае 8 MB это совсем немного, поэтому память успешно выделяется.

[Dmitriy40]

iakovk в сообщении #1316323 писал(а):

Когда программа исчерпывает выделенную область и хочет получить еще, возникает страничный отказ.

А я снова повторю, для отказ возникнет не при выделении виртуальной памяти, а при записи в выделенную память, когда не хватит размера физической памяти плюс размера файла подкачки. Пример с успешным выделением $8\cdot10^{18}$ (под x64 разумеется) байтов весьма показателен. Вы же описали другой тип отказа, исчерпание виртуальной памяти, когда не хватает адресов памяти для стека и он "налезает" на что-то ещё. При этом может оставаться ещё много свободной памяти (как физической, так и в файле подкачки).

[Munin]

realeugene в сообщении #1316322 писал(а):

Основное адресное пространство процесса, в том числе, содержащее стеки нитей, единое и плоское.

Тогда почему бы стек не начинать с адреса 0xFFFFFFFFFFFFFFFC? И не было бы никакого ограничения в 1 Мб.

[Dmitriy40]

Munin в сообщении #1316346 писал(а):

Тогда почему бы стек не начинать с адреса 0xFFFFFFFFFFFFFFFC? И не было бы никакого ограничения в 1 Мб.

Может быть потому что все процессы/потоки/нити одного приложения сидят в общем адресном пространстве, а стеки у них разные?

[realeugene]

Munin,


1. Самые старшие адреса обычно используются для других целей.
2. В скриптах линкера указывается максимальный размер стека. По умолчанию под Виндами - 1 МБ. Но не запрещено попросить и больше при сборке проекта. Заранее. И место в адресном пространстве будет зарезервировано.
3. Как тут уже ранее упоминали, на каждую нить выделяется два стека, один именно такого размера, по поводу второго я не уверен, возможно, какого-то фиксированного. Нитей в процессе может быть много. Стеков различных нитей тоже может быть много. Большой зарезервированный размер стека означает бессмысленный расход адресного пространства (но ещё не памяти). На 32-разрядных системах это уже может оказаться существенным.
4. Адресное пространство для каждого стека резервируется (никто другой там уже не разместится), но память выделяется только при первом обращении к каждой странице. Это не приводит к преждевременному расходу памяти. Если же глубина вызовов большая или на стеке размещено много больших объектов, то рано или поздно весь этот размер стека окажется закоммиченным (а иначе зачем резервировать много?) После окончания стекоёмких вычислений, эта память останется бесполезно закоммиченной и не сможет быть переиспользована для других вычислений (например, другими процессами). Глубокие стеки - это зло. 1МБ - это компромисс: если алгоритм в него не влазит, стоит задуматься. Или зарезервировать больше, или переписать алгоритм.
5. Большие объекты лучше аллокировать на куче. После освобождения объекта на куче память может быть переиспользована другими нитями. Очень большие объекты аллокируются непосредственно средствами OS, и после их освобождения их память может быть сразу же переиспользована любым другим процессом. Это не засоряет память мусором.


В ядре Линукса стек у каждой нити совсем крошечный. И ничего.

-- 30.05.2018, 21:33 --

Dmitriy40 в сообщении #1316356 писал(а):

Может быть потому что все процессы/потоки/нити одного приложения сидят в общем адресном пространстве, а стеки у них разные?

У каждого процесса своё виртуальное адресное пространство. Но у всех нитей одного процесса оно общее.

[arseniiv]

Qlin в сообщении #1316241 писал(а):

Я разбираюсь, что такое локальные переменные.

В принципе не обязательно знать о стеке, чтобы понимать локальные переменные. Локальные переменные вообще могут быть у любого блока (если язык позволяет), а не только у функции. И тут, во-вторых, они могут в любом случае сидеть и в регистрах, не попадая в стек, или ещё где-то быть, а во-первых, локальность — это свойство ровно области видимости и времени жизни переменной (а переменная — это имя, с которым связано значение, и даже не всегда кстати изменяемое), аппаратная реализация тут до нужды в оптимизации должна быть совершенно по барабану.

[Munin]

Dmitriy40 в сообщении #1316356 писал(а):

Может быть потому что все процессы/потоки/нити одного приложения сидят в общем адресном пространстве, а стеки у них разные? ;-)

Процессы - ни в коем случае не в одном.

realeugene в сообщении #1316358 писал(а):

1. Самые старшие адреса обычно используются для других целей.

Традиционно. Как и размер 1 Мб выбран традиционно. Как и термины типа "сегмент такой, сегмент сякой" (sections переводится как "сегменты").

Так что ссылаться на одну традицию, утверждая устарелость другой соседней, - мягко говоря, нелогично.

Банальности вы могли бы и не писать.

arseniiv в сообщении #1316363 писал(а):

В принципе не обязательно знать о стеке, чтобы понимать локальные переменные.

Но очень желательно - знать.

[Dmitriy40]

Я не вполне знаком с устоявшейся (ой ли?) русской терминологией, потому и перечислил возможные варианты.
К примеру AnVir Task Manager и Диспетчер задач Windows называют это потоки в рамках одного процесса и сидят они в общем адресном пространстве. Думаю это точный эквивалент нитей в текстах выше.
В остальном согласен с realeugene.

[realeugene]

Munin в сообщении #1316366 писал(а):

(sections переводится как "сегменты").

У грамотных переводчиков ни в коем случае. Есть Memory segments и есть PE file sections. Это - принципиально разные термины.

Тот адрес, который вы написали ранее, в Виндах относится к System Virtual Address Space, общему для всех процессов в системе, и для стека использован быть не может. В Линуксе старшие адреса используются для той же цели. Если вы хотите написать свою операционку с другим распределением виртуальных адресов - пожалуйста, пишите.

[Munin]

realeugene в сообщении #1316384 писал(а):

У грамотных переводчиков ни в коем случае.

Грамотные переводчики пользуются устоявшимися переводами. А те, которые мнят себя грамотными, но не знают русской терминологии...

realeugene в сообщении #1316384 писал(а):

Если вы хотите написать свою операционку с другим распределением виртуальных адресов - пожалуйста, пишите.

Я не хочу. Я намекаю, что существующие могли бы быть написаны иначе. Но вы намёков не понимаете. На этом закончим.

[arseniiv]

Munin в сообщении #1316366 писал(а):

Но очень желательно - знать.

Но приоритеты надо тоже расставлять. Иначе так можно закопаться вообще в конкретную архитектуру, скажем, x86, а это ужас кошмарный. Впрочем, я немного додумал, что вопрос «что такое локальные переменные» — это вопрос в рамках изучения программирования или какого-то языка, и если это не так, то пускай стек.

-- Чт май 31, 2018 11:46:20 --

(Традиционная рубрика аналогий)

Аналогия: человек решил разобраться, как попасть в некоторый магазин и для этого зачем-то решил разбираться, какими движениями он ходит. Безусловно, это знание ему поможет в некоторых случаях, но это невидение за деревьями леса, ему нужно знать допустимые операции, а не выражение через что-то ниже уровнем (ибо допустимые операции всё равно придётся для какого-то уровня изучить, и иллюзия того, что они для более нижнего более естественны и понятны — это лишь вредная иллюзия).

[iakovk]

Dmitriy40 в сообщении #1316339 писал(а):

А я снова повторю
, для отказ возникнет не при выделении виртуальной памяти

Вы не понимаете, что такое страничный отказ. Я вполне корректно (но кратко) описал механизм выделения памяти в Windows под стек режима пользователя, а вовсе не тип отказа. Если вы считаете, что я здесь неправ, укажите конкретно, в чем.

Munin в сообщении #1316346 писал(а):

И не было бы никакого ограничения в 1 Мб.

А его и нет.