Стеки и данные потоков

[Yuriy Zhilovets]

Привет всем!

Просьба сказать, верно ли я понимаю, внутренности SPF.

1. Основной процесс
Получает управление от системы с выделенным стеком.
Этот стек в _WNDPROC-CODE делится на две части: меньшая (3968 байтов,
кстати, откуда эта цифра?) идет под стек возвратов, остальное - под
основной стек.
CREATE-PROCESS-HEAP создает
а) кучу основного потока (используется куча, потому что ей проще
управлять?) для последующих ALLOCATE
б) место для локальных переменных - уже выделенных плюс какой-то кусок
EXTRA-MEM. Начало этого места заносится в EDI и сохраняется там все
время работы программы.

2. Другие потоки
Стеки - как в основном процессе
Куча и локальное хранилище - как в основном процессе, но словом
CREATE-HEAP (отличаются только отсутствием сериализации)

Никакие системные особенности, связанные с TLS, не используются.

Ю. Жиловец

[Andrey Cherezov]

Добрый день, Yuriy Zhilovets!

Ваше сообщение от 10.05.2007 20:19:
> Просьба сказать, верно ли я понимаю, внутренности SPF.
>  
Верно.
> Этот стек в _WNDPROC-CODE делится на две части: меньшая (3968 байтов,
> кстати, откуда эта цифра?)
Это самое узкое место в SPF. Принятая там планировка стеков может приводить
к перекрыванию областей стека при системных колбэках. Указанное число
взялось
из метода тыка. Другие числа могут вызывать проблемы (по крайней мере в
старых
виндах, когда число подбиралось).

Если бы я сейчас проектировал форт с нуля, то место для стека данных форта
выделял бы из хипа.

[Yuriy Zhilovets]

Добрый вечер, Андрей!

>Это самое узкое место в SPF. Принятая там планировка стеков может приводить
>к перекрыванию областей стека при системных колбэках.
>
Линукс выделяет под стек 1 мб и коммитит еще один. Мне кажется, этого
должно хватить.
Наверное, современные версии Windows дают не меньше.

Еще вопрос: перед блоком переменных USER выделяется лишняя ячейка, в
которую заносится адрес CREATE-HEAP.
Это для унификации с ALLOCATE, которая тоже делает лишнюю ячейку?

Ю. Жиловец

[Dmitry Yakimov-2]

Привет,

Yuriy Zhilovets wrote:

> Привет всем!
>
> Просьба сказать, верно ли я понимаю, внутренности SPF.
>
> 1. Основной процесс
> Получает управление от системы с выделенным стеком.
> Этот стек в _WNDPROC-CODE делится на две части: меньшая (3968 байтов,
> кстати, откуда эта цифра?) идет под стек возвратов, остальное - под
> основной стек.
>  

Не совсем верно - 3968 идет под стек данных, а остальное под стек возвратов.
Под стек данных в Windows можно выделить и больше - Windows
перехватывает AV обращения к этой памяти и автоматически довыделяет.

> CREATE-PROCESS-HEAP создает
> а) кучу основного потока (используется куча, потому что ей проще
> управлять?) для последующих ALLOCATE
>  
А кроме кучи ничего и не сделать. Виртуальную память выделять - будет
дорого для выделения мелких кусочков, которых большинство.

> б) место для локальных переменных - уже выделенных плюс какой-то кусок
> EXTRA-MEM. Начало этого места заносится в EDI и сохраняется там все
> время работы программы.
>  
Лучше сказать для переменных потока.
> 2. Другие потоки
> Стеки - как в основном процессе
> Куча и локальное хранилище - как в основном процессе, но словом
> CREATE-HEAP (отличаются только отсутствием сериализации)
>
> Никакие системные особенности, связанные с TLS, не используются.
>  

Да. Верно.

Дмитрий.

[Dmitry Yakimov-2]

Andrey Cherezov wrote:

>
>> Этот стек в _WNDPROC-CODE делится на две части: меньшая (3968 байтов,
>> кстати, откуда эта цифра?)
>>    
> Это самое узкое место в SPF. Принятая там планировка стеков может приводить
> к перекрыванию областей стека при системных колбэках. Указанное число
> взялось
> из метода тыка. Другие числа могут вызывать проблемы (по крайней мере в
> старых
> виндах, когда число подбиралось).
>
> Если бы я сейчас проектировал форт с нуля, то место для стека данных форта
> выделял бы из хипа.
>  

Еще лучше из виртуальной памяти, с защитой страниц по краям от записи.


Дмитрий.

[Yuriy Zhilovets]

Some javascript/style in this post has been disabled (why?)

Dmitry Yakimov пишет:

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

Я смотрю, в Линуксе понятия кучи нет. Очевидно, там более изощренные механизмы выделения памяти.

Ю. Жиловец

[Dmitry Yakimov-2]

Yuriy Zhilovets wrote:
> Dmitry Yakimov пишет:
>> А кроме кучи ничего и не сделать. Виртуальную память выделять - будет
>> дорого для выделения мелких кусочков, которых большинство.
>>  
> Я смотрю, в Линуксе понятия кучи нет. Очевидно, там более изощренные
> механизмы выделения памяти.

Понятие кучи и пошло от Unix :)
Вызов malloc() выделяет из хипа, находится в glibc.

Если без glibc то например так:
int fd = open ("/dev/zero", O_RDONLY);
char* memory = mmap (NULL, page_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE, fd, 0);
close (fd);

Дмитрий.

[Yuriy Zhilovets]

Dmitry Yakimov пишет:

>Понятие кучи и пошло от Unix :)
>
Ну это вряд ли. Кучу придумали еще в PL/1.
Я собственно, имел в виду, что в API нет явного создания разных куч.
Наверно, алгоритмы распределителя памяти сами разбираются с мелкими кусками.

Ю. Жиловец