Когда случается stack overflow?
 

Несколько запусков этого кода дали разные результаты, а именно: 3299, 3501, 3301. (Примечание: результаты были на столько разными только от того, что менялся текст внутри trace(), если текст не менять, то результаты находятся примерно в пределах 3300-3305). С чем это связано? И почему есть разница даже при выполнении абсолютно одинакового кода?
(Примечание 2: как и следовало ожидать, возвращая вызов функции вместо того, чтобы просто ее вызывать, несколько оптимизирует производительность / позволяет запихать больше вызовов в стек, т.как все функции все равно всегда что-то возвращают).

А почему? Ведь после return recure(); всё ровно кода не исполняется. Значит если в конце каждой функции ставить return, код будет быстрее выполнятся?

wvxvw, я однажды заметил в профайлере, что если в теле функции есть try..catch, то объекты, используемые в ней, начинают множиться в памяти... Возможно такие разбросы как-то с этим связаны?

немного оффтоп у меня в этом коде цифры в пределах 2800 (тоже скачут), глубина стека зависит от выделяемой оперативной памяти или чего-то другого?

Ну собственно, по семантике, функция отличается от процедуры тем, что что-то возвращает (поэтому есть обязательный возвращаемый тип, и если не нужно возвращать ничего, то возвращают undefined, т.е. экземпляр класса void). Когда функция компилируется, у нее всегда в конце есть опкод, который должен вернуть что-то. Либо значение заданое пользователем, либо, если ничего не задано, то вернет undefined (void).
T.o. елси мы сами чего-то вернем, то не будет "ненужного" кода для возврата "ничего".
На сколько я до сегодняшнего дня представлял себе устройство стека, то у него есть своя "отдельная" память. Но я так же думал, что выделяется она динамически, а ограничение делается не на размер занятой памяти, а на количество вхождений. Т.е. не важно, что функция которая на стеке делает, и сколько памяти занимает, если сказано, что размер стека = 100 вызовов, значит 100. А оказывается, что нет...

А какое значение имеет max-recursion-depth? И еще. Мне показалось, что это ограничение глубины имеет место только для рекурсивных вызовов. Когда тестировал дерево и самый нижний ребенок спрашивал у родителя корневой узел (аналог свойства stage), тот в свою очередь обращался к своему родителю, то эта цепочка была много больше значения max-recursion-depth. Тогда я специально сделал тест с применением рекурсии и получил RTE при превышении, как мне казалось, порога. Однако я не стал проверять соответствует ли количество вызовов заявленной величине depth.

Ну так собственно, тут рекурсия налицо. И я почему-то помню, что было ограничение в 255 витков, и тут вдруг функция вызывается рекурсивно несколько тысяч раз?

Видимо, пока не закончится память под выпавшие Error.

В моем понимании, я в таком случае должен был бы получить out-of-memory. Как бы понятно, что стек не резиновый, но не понятно по какому принципу ограничение. И почему оно определяется динамически... Т.е. из практических соображений было бы гораздо удобнее знать, что в стеке, например, не может быть более 100 вызовов, и не нужно было бы длинную-предлинную рутину всю заворачивать в try-catch, т.как это чревато другими вещами.

ЗЫ. Скомпилировал с dump-config там по умолчанию 1000 витков рекурсии, пробовал ставить ограничение в 10 - никаких изменений.

в раззных версиях плеера - разные результаты. В ранних рекурсия глубже. А при выносе try..catch "за скобки" - еще глубже рекурсия получается