Re: performance of exception handling

[Florian Weimer <fweimer@redhat.com>]

* Thomas Neumann via Gcc:

> Currently, exception handling scales poorly due to global mutexes when
> throwing. This can be seen with a small demo script here:
> https://repl.it/repls/DeliriousPrivateProfiler
> Using a thread count >1 is much slower than running single threaded.
> This global locking is particular painful on a machine with more than a
> hundred cores, as there mutexes are expensive and contention becomes
> much more likely due to the high degree of parallelism.
>
> Of course conventional wisdom is not to use exceptions when exceptions
> can occur somewhat frequently. But I think that is a silly argument, see
> the WG21 paper P0709 for a detailed discussion.

Link: <https://wg21.link/P0709>

I'm not sure if your summary is correct.

The claim in the paper that program bugs should not result in catchable
exceptions is also not what matches my limited experience with
application servers: They tend to install an exception handler of last
resort to catch unexpected exceptions (“bugs”) from processed requests
and log them, instead of letting them terminate the entire application
server.

> In particular since there is no technical reason why they have to be
> slow, it is just the current implementation that is slow.

I agree, the present state is not inherently due to the exception
handling model, it's a consequence of the current implementation.

> In the current gcc implementation on Linux the bottleneck is
> _Unwind_Find_FDE, or more precisely, the function dl_iterate_phdr,
> that is called for every frame and that iterates over all shared
> libraries while holding a global lock.
> That is inherently slow, both due to global locking and due to the data
> structures involved.

In particular, the libgcc unwinder relies on the global lock to protect
its own cache, so we cannot remove the lock from glibc.

> And it is not easy to speed that up with, e.g., a thread local cache,
> as glibc has no mechanism to notify us if a shared library is added or
> removed.

It is of course possible to change glibc.

My current preferred solution is something that moves the entire code
that locates the relevant FDE table into glibc.  This is all the code in
_Unwind_IteratePhdrCallback until the first read_encoded_value_with_base
call.  And the callback mechanism would be gone, so _Unwind_Find_FDE
would call __dl_ehframe_find (see below) and then the reamining
processing in _Unwind_IteratePhdrCallback.

The glibc interface would look like this:

/* Data returned by dl_find_ehframe.  */
struct dl_ehframe_info
{
  /* The link map of the object which contains the address.  */
  const struct link_map *dlehf_map;

  /* A pointer to its dynamic section.  This is a null pointer in
     statically linked applications.  */
  const ElfW(Dyn) *dlehf_dynamic;

  /* A pointer to the start of the PT_GNU_EH_FRAME segment for the
     object.  This is a null pointer if the object does not contain
     such a segment.  */
  const void *dlehf_ehframe;

  /* The size of the segment, or zero if not present.  */
  size_t dlehf_ehframe_size;

  /* Text and data base for the DWARF information in the segment.  */
  ElfW(Addr) dlehf_text_base;
  ElfW(Addr) dlehf_data_base;
};

/* Find the PT_GNU_EH_FRAME segment of the object which contains
   ADDRESS and writes information to it to *RESULT.  Return -1 if
   nothing was found, or 0 on success.  (*RESULT can be written to on
   failure, too.)  */
int __dl_ehframe_find (ElfW(Addr) __address,
                       struct dl_ehframe_info *__result)
  __THROW __nonnull ((2)) __attribute_warn_unused_result__;

It is the responsiblity of the glibc implementation of __dl_ehframe_find
to provide proper synchronization with the dynamic loader.  We can start
out with a lock-based implementation, as we have it today, and optimize
it later.

Based on prior discussions, this works because unwinding with a corrupt
stack or a stack containing unmapped objects is already undefined today,
so the live stack keeps all pointers returned from __dl_ehframe_find
valid.

The cache as it exists today would be removed from libgcc, but we
probably want to add a small cache that avoids the need to call into
glibc while unwinding through the same object (in which case we probably
should add boundary information to struct dl_ehframe_info).

The advantage of doing it this way is that it does not require
recompiling and relinking objects.

Thanks,
Florian