[erlang-questions] System getting hang after running normal recursion program

[Richard Carlsson]

Exactly. Erlang processes manage their own stacks and reallocate and grow
them as needed. This means that stacks can start out very small (like 2-4
k) and you can have millions of processes without running out of address
space for stacks.


        /Richard

2017-10-07 15:23 GMT+02:00 Leandro Ostera <leandro@REDACTED>:

> @Richard, so there's no static stack limit, but rather the stack grows
> dynamically and the evaluation will be RAM-bound?
>
> On Sat, Oct 7, 2017 at 3:04 PM Richard Carlsson <
> carlsson.richard@REDACTED> wrote:
>
>> Your small function has no way to terminate, and very quickly eats up
>> your system RAM with its ever growing stack. The CPU load is not the
>> problem.
>>
>>
>>         /Richard
>>
>> 2017-10-07 14:14 GMT+02:00 Arun <arunp@REDACTED>:
>>
>>> Hi Leandro,
>>>
>>> Am aware about tail recursion in erlang, but here I am talking about
>>> recursion which is not tail recursive. Here is the code snippet;
>>>
>>> start(N) ->
>>>     N*start(N-1).
>>>
>>> Here the function is not tail recursive and it is in an infinite loop.
>>> If run this function my system is getting hang. That why i got the doubt
>>> why it is making my system to hang and how the erlang scheduler will behave
>>> in this scenario.?
>>> Regards,
>>> Arun P.
>>>
>>>
>>> On Saturday 07 October 2017 04:07 PM, Leandro Ostera wrote:
>>>
>>> Hej Arun, hi.
>>>
>>> Depending on your recursion, you may or may not be building up a stack
>>> that will at some point crash. I am unsure about how C compilers typically
>>> deal with tail-recursion, but tail call optimization is automatically
>>> performed in the Erlang VM for you.
>>>
>>> From the Learn You Some Erlang book chapter on Recursion (
>>> http://learnyousomeerlang.com/recursion):
>>>
>>> *Note:* tail recursion as seen here is not making the memory grow
>>> because when the virtual machine sees a function calling itself in a tail
>>> position (the last expression to be evaluated in a function), it eliminates
>>> the current stack frame. This is called tail-call optimisation (TCO) and it
>>> is a special case of a more general optimisation named *Last Call
>>> Optimisation* (LCO).
>>>
>>> LCO is done whenever the last expression to be evaluated in a function
>>> body is another function call. When that happens, as with TCO, the Erlang
>>> VM avoids storing the stack frame. As such tail recursion is also possible
>>> between multiple functions. As an example, the chain of functions a()
>>> -> b(). b() -> c(). c() -> a(). will effectively create an infinite
>>> loop that won't go out of memory as LCO avoids overflowing the stack. This
>>> principle, combined with our use of accumulators is what makes tail
>>> recursion useful.
>>>
>>> Hope this helps!
>>>
>>> On Sat, Oct 7, 2017 at 9:03 AM Arun <arunp@REDACTED> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I tried to run normal recursion program from erlang shell, the program
>>>> runs infinitely and it is doing addition of numbers. But its been
>>>> observed that soon after starting the program entire PC is getting hang.
>>>>
>>>> My doubt is that, why my PC is getting hang. ? , if something is going
>>>> wrong, the erlang vm should be able to handle it, like in C if we run
>>>> some recursion program infinity, it will crash by throwing segmentation
>>>> fault error.
>>>>
>>>> What will be happening in the VM if I run a normal recursion program in
>>>> erlang infinitely ?
>>>>
>>>> What will be the behavior of erlang scheduler in this scenario ?
>>>>
>>>> Can somebody please assist me on this issue.
>>>>
>>>> Thanks in advance
>>>> Arun P.
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171007/d7cee2c0/attachment.htm>