2 ms·

All of this hinges around the global lock, although I'm not sure what you mean exactly. Are you talking about memory allocation, a lock that exception handling

• tneumann 5y ago
  The main problem is the unwinding lock. Memory allocation is a bit unfortunate, too, but much less so. Note that I am trying to fix the unwinding problem, I have submitted a patch to libunwind to eliminate the contention during unwinding: https://reviews.llvm.org/D120243 https://reviews.llvm.org/D120243 It require application support, unfortunately, as there is currently no way that libunwind can figure out if a shared library has been added or removed. But if you are willing to indicate that from within the application the performance problem is mostly fixed. The memory allocation issue remains, but I can live with that. I cannot live with single threaded unwinding.
  • drmeister 5y ago
    Thanks for that patch - I'll watch this with great interest. Is there a problem if dynamic libraries invoke dlopen/dlclose they also need to call the sync function - correct? I'm asking because we've developed a Common Lisp implementation that interoperates with C++ and it uses exception handling to unwind the stack (https://github.com/clasp-developers/clasp.git https://github.com/clasp-developers/clasp.git). We hit this global lock in unwinding problem a lot - it causes us a lot of grief.