Что такое безопасный максимальный размер стека или как измерить использование стека?

для полноты, я добавляю версию opc0de это на определение количества используемого стека это будет работать как для x86 32-и 64-разрядных версий Windows (функция opc0de предназначена только для Win32).

функция opc0de запрашивает адрес базы стека и самой низкой фиксированной базы стека из окна информационный блок потока (TIB). Есть два отличия между x86 и x64:

• Тиб указывает на FS сегмент регистрируется на Win32, но по GS на Win64 (см. здесь)
• абсолютные смещения элементов в структуре различаются (в основном потому, что некоторые элементы являются указателями, т. е. 4 байта и 8 байтов на Win32/64, соответственно)

дополнительно обратите внимание, что есть небольшая разница в коде BASM, потому что на x64,abs требуется, чтобы ассемблер использовал абсолютное смещение от регистра сегмента.

поэтому версия, которая будет работать как на Win32, так и на Win64, выглядит так:

{$IFDEF MSWINDOWS}
function CommittedStackSize: NativeUInt;
//NB: Win32 uses FS, Win64 uses GS as base for Thread Information Block.
asm
 {$IFDEF WIN32}
  mov eax, [fs:04h] // TIB: base of the stack
  mov edx, [fs:08h] // TIB: lowest committed stack page
  sub eax, edx      // compute difference in EAX (=Result)
 {$ENDIF}
 {$IFDEF WIN64}
  mov rax, abs [gs:08h] // TIB: base of the stack
  mov rdx, abs [gs:10h] // TIB: lowest committed stack page
  sub rax, rdx          // compute difference in RAX (=Result)
 {$ENDIF}
{$ENDIF}
end;

Я помню, что я заполнял все доступное пространство стека нулями на init много лет назад и считал смежные нули на deinit, начиная с конца. Это дало хорошую "высокую отметку воды", при условии, что вы отправляете свое приложение через свои шаги для пробных запусков.

я выкопаю код, когда вернусь немобильным.

Update: OK принцип продемонстрирован в этом (древнем) коде:

{***********************************************************
  StackUse - A unit to report stack usage information

  by Richard S. Sadowsky
  version 1.0 7/18/88
  released to the public domain

  Inspired by a idea by Kim Kokkonen.

  This unit, when used in a Turbo Pascal 4.0 program, will
  automatically report information about stack usage.  This is very
  useful during program development.  The following information is
  reported about the stack:

  total stack space
  Unused stack space
  Stack spaced used by your program

  The unit's initialization code handles three things, it figures out
  the total stack space, it initializes the unused stack space to a
  known value, and it sets up an ExitProc to automatically report the
  stack usage at termination.  The total stack space is calculated by
  adding 4 to the current stack pointer on entry into the unit.  This
  works because on entry into a unit the only thing on the stack is the
  2 word (4 bytes) far return value.  This is obviously version and
  compiler specific.

  The ExitProc StackReport handles the math of calculating the used and
  unused amount of stack space, and displays this information.  Note
  that the original ExitProc (Sav_ExitProc) is restored immediately on
  entry to StackReport.  This is a good idea in ExitProc in case a
  runtime (or I/O) error occurs in your ExitProc!

  I hope you find this unit as useful as I have!

************************************************************)

{$R-,S-} { we don't need no stinkin range or stack checking! }
unit StackUse;

interface

var
  Sav_ExitProc     : Pointer; { to save the previous ExitProc }
  StartSPtr        : Word;    { holds the total stack size    }

implementation

{$F+} { this is an ExitProc so it must be compiled as far }
procedure StackReport;

{ This procedure may take a second or two to execute, especially }
{ if you have a large stack. The time is spent examining the     }
{ stack looking for our init value ($AA). }

var
  I                : Word;

begin
  ExitProc := Sav_ExitProc; { restore original exitProc first }

  I := 0;
  { step through stack from bottom looking for $AA, stop when found }
  while I < SPtr do
    if Mem[SSeg:I] <> $AA then begin
      { found $AA so report the stack usage info }
      WriteLn('total stack space : ',StartSPtr);
      WriteLn('unused stack space: ', I);
      WriteLn('stack space used  : ',StartSPtr - I);
      I := SPtr; { end the loop }
    end
    else
      inc(I); { look in next byte }
end;
{$F-}


begin
  StartSPtr := SPtr + 4; { on entry into a unit, only the FAR return }
                         { address has been pushed on the stack.     }
                         { therefore adding 4 to SP gives us the     }
                         { total stack size. }
  FillChar(Mem[SSeg:0], SPtr - 20, $AA); { init the stack   }
  Sav_ExitProc := ExitProc;              { save exitproc    }
  ExitProc     := @StackReport;          { set our exitproc }
end.

(от http://webtweakers.com/swag/MEMORY/0018.PAS.html)

хорошая вещь в этом подходе-у вас есть нулевая производительность и нет операции профилирования во время запуска программы. Только после выключения цикл-до-измененного-значения-найденный код съедает циклы процессора. (Мы закодировали это позже в сборке.)

даже если все 8 потоков должны были приблизиться к использованию их 1 МБ стека, это только 8 МБ виртуальной памяти. IIRC, начальный размер стека по умолчанию для потоков-64K, увеличивающийся при сбоях страницы, если не достигнут предел стека потока процесса, и в этот момент я предполагаю, что ваш процесс будет остановлен с помощью messageBox "Stack overflow": ((

Я боюсь, что уменьшение предела стека процесса $MAXSTACKSIZE не облегчит вашу проблему фрагментации/подкачки, если что-нибудь. Тебе нужно больше ОЗУ, так что резидентный набор страниц вашего мега-фото-приложения больше и так молотить уменьшен.

сколько потоков есть, в целом, в среднем, в вашем процессе? Диспетчер задач может показать это.

Rgds, Мартин!--1-->

хотя я уверен, что вы можете уменьшить размер стека потока в своем приложении, я не думаю, что он будет решать основную причину проблемы. Теперь вы используете 8-ядерную машину, но что происходит на 16-ядре или 32-ядре и т. д.

с 32-битным Delphi у вас есть максимальное адресное пространство 4GB, и поэтому это ограничивает вас в некоторой степени. Возможно, вам придется использовать меньшие стеки для некоторых или всех ваших потоков, но вы все равно столкнетесь с проблемами на достаточно большом машина.

Если вы поможете вашему приложению масштабироваться лучше на больших машинах, вам может потребоваться выполнить один или другой из следующих шагов:

1. избегайте создания значительно большего количества потоков, чем ядра. Используйте архитектуру пула потоков, доступную для подключаемых модулей. Без использования среды .net, чтобы сделать это легко, вы будете лучшим кодированием против API пула потоков Windows. Тем не менее, должна быть хорошая обертка Delphi.
2. сделки с шаблоны выделения памяти. Если ваши потоки выделяют смежные блоки в области 200 МБ, это вызовет чрезмерное напряжение на вашем распределителе. Я обнаружил, что часто лучше всего выделять такие большие объемы памяти в меньших блоках фиксированного размера. Этот подход работает вокруг проблем фрагментации, с которыми вы сталкиваетесь.

уменьшение $MAXSTACKSIZE не будет работать, потому что Windows всегда будет выравнивать стек потоков до 1 Мб (?).

один (возможно?) способ предотвратить фрагментацию-зарезервировать (не alloc!) виртуальная память (с VirtualAlloc) перед созданием потоков. И отпустите его после запуска потоков. Таким образом, Windows не может использовать зарезервированное пространство для потоков, поэтому у вас будет непрерывная память.

или вы можете сделать свой собственный менеджер памяти для больших фотографий: зарезервировать много виртуальная память и память alloc из этого пула вручную. (вам нужно самостоятельно вести список используемой и используемой памяти).

по крайней мере, это теория, не знаю, действительно ли это работает...