[erlang-questions] Heads-up: The cost of get_stacktrace()

[Tony Rogvall]

Thank you for sharing.

/Tony

On 5 nov 2013, at 21:36, Richard Carlsson <carlsson.richard@REDACTED> wrote:

> (Executive summary: exceptions cheap, but erlang:get_stacktrace() kind of expensive; also, avoid 'catch Expr'.)
> 
> We have wrestled for some time with some very strange unresponsiveness and high amounts of garbage collection, and finally managed to track down the problem. It was in a piece of code that matches some input data against a number of different "patterns", trying one possibility at a time in a failure-driven loop. The actual problem was a wrapper that executed each call in a try/catch, with a default catch clause looking something like this:
> 
>  try match(Pattern, Data)
>  catch
>    ...
>    Class:Term ->
>      {foo_error, {Class, Term, erlang:get_stacktrace()}}
>  end
> 
> The stacktrace was usually discarded again further up and the whole thing was retried with another "pattern". This code got executed tens of thousands of times per second. When we removed the call to get_stacktrace(), the system instantly started to behave much better.
> 
> The purpose of this mail, then, is both to warn about sloppy use of get_stacktrace() and to clarify how stack traces are handled and wherein the costs lie.
> 
> First of all, triggering an exception is quite cheap. The necessary stack trace information (by default, 8 pointers) is quickly saved in an opaque blob, and control gets passed up to the nearest catch handler (if there is one). If there is a handler, normal Erlang execution will resume, trying to match the catch-clauses. If no catch clause matches, the exception state is unchanged and we look for the next catch handler, until either some catch clause matches or the top of the call stack is reached (which will terminate the process).
> 
> If a catch clause matches, execution just continues and no extra cost is incurred as long as you don't try to inspect the stack trace. If none of the clauses match, the only cost was that of trying the clause patterns and guards. For example, terminating a process by "exit(normal)" has very little overhead even if it passes through a number of catch handlers that just pass it on upwards, because even the process exit signal will not contain the stack trace. And using throw/catch for nonlocal return out of a deep recursion is very cheap.
> 
> *But* if someone wants to actually look at the stack trace of the exception, the "opaque blob" mentioned above must be reified as an Erlang term, by calling erlang:get_stacktrace(). This amounts to looking up the module and function name and arity corresponding to each of the saved code pointers, and creating a corresponding list of MFA tuples on the heap. (This also happens if the process terminates due to an exception of type 'error' or 'throw', to include the stack trace in the exit signal.)
> 
> In addition, as of Erlang/OTP R15 this operation is 4-5 times(!) more expensive than it used to be pre-R15, because now the stack trace also includes file names and line numbers. That's more data to be allocated on the heap, but most of the cost is probably in traversing the tables that map bytecode regions to corresponding source file regions (these tables are created by the compiler and are included in the .beam files). For us, this difference meant that we went from "mysteriously high activity, but not critical" under R14 to "random bursts of unresponsiveness" under R15, and it took us a lot of effort to figure out what was going on.
> 
> So the general advice is: Don't call erlang:get_stacktrace() just because you can. If you don't have a real reason for catching every possible exception, just let the uninteresting ones fall through. Avoid the temptation to have a catch-all clause like in the example above, that re-packages the exception wrapped in a tuple with some tag that you happen to like. In particular if there's a chance that the code will be re-tried over and over again. If you don't intend to handle the exception, then let it remain an exception for as long as possible and don't turn the stack trace into a term, because that's when you pay.
> 
> It's of course still valid to call get_stacktrace() in many situations, e.g. when the process is on its way to give up, or to write the crash information to a log, or for something that only happens rarely and the stack trace information is useful - but never in a library function that might be used heavily in a loop.
> 
> Finally, this is also another reason to rewrite old occurrences of 'catch Expr' into 'try Expr catch ... end', because it basically works like this:
> 
>  try Expr
>  catch
>    throw:Term -> Term;
>     exit:Term -> {'EXIT', Term};
>    error:Term -> {'EXIT', {Term, erlang:get_stacktrace()}}
>  end
> 
> so what happens if you use one of the following old idioms?:
> 
>  ...
>  catch foo(...),  % for side effect, ignore the result
>  ...
> 
> or
> 
>  case catch foo(...) of
>    {'EXIT', Reason} -> ...;
>    Result -> ...
>  end
> 
> Well, when the exception type is 'error', the catch will build a result containing the symbolic stack trace, and this will then in the first case be immediately discarded, or in the second case matched on and then possibly discarded later. Whereas if you use try/catch, you can ensure that no stack trace is constructed at all to begin with.
> 
> Sorry that this got a bit long, but I think that was all.
> 
>    /Richard
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131106/a6636331/attachment.htm>