freenode/#clasp - IRC Chatlog
Search
15:36:15
Bike
C++ exception handling on linux sucks apparently with multithreading. We do a lot of that right now so we get poor parallel performance in code that unwinds a lot. they're not likely to fix anything on their end, but once cleavir2 is in we'll unwind a lot less and it will be less of a problem. in the meantime, it just means we don't get much of a speed improvement.
15:39:51
Bike
in the meantime i can also get the personality working, which should save some time, though not reduce contention.
16:46:47
kpoeck
do we have source-location information for constant or variables? EXT:*SOURCE-LOCATION-KINDS* -> (:CLASS :METHOD :FUNCTION :COMPILER-MACRO :METHOD-COMBINATION :TYPE :SETF-EXPANDER) doesn't seem to fit constant or variables
17:50:04
drmeister
What is you mental timeline for cleavir2 integration? Can we implement the unwinding codenow?
18:02:01
drmeister
If it's the same way that beach is going to organize it - then could we not organize ours the same way and start using it?
18:56:47
drmeister
What would it take to implement cleaver2-like stack unwinding. You have the hir instructions already don’t you?
19:08:37
Bike
also i'm not sure beach has finished working out all the details of local exits out of unwind-protects, and stuff.
21:12:32
drmeister
While evaluating some new lock algorithms (exposed via LD_PRELOAD interposition on the pthread_lock and condvar interfaces), I noticed that C++ catch and throw on Solaris/SPARC compiled with GCC 4.9.0 will take runtime paths that take locks and impede scaling. Specifically, if you have a set of threads that simply execute "try { throw 20; } catch (int e) {;}", they won't scale as expected because of runtime locks.
21:12:32
drmeister
Unwind_RaiseException and Unwind_Find_FDE always appear on the stack when we encounter the contention. Interestingly, I didn't see any evidence of this behavior on Ubuntu 14.04 on x86.
21:33:07
drmeister
This might be the dl_iterate_phdr lock used to find the FDE from the eh_frame unwind tables. According to this patch http://marc.info/?l=gcc-patches&m=129102935322345&w=2 if you use the Solaris instead of GNU linker you won't get the binary search eh_frame_hdr table so will end up doing linear searches. There seem to be some other workaround for Solaris ld deficiencies in the unwinding support, so that might be why you
21:33:07
drmeister
aren't seeing this on GNU/x86. Maybe try using GNU ld with GCC on Sparc and see if that reduces the contentions?
21:33:59
Bike
dl_iterate_phdr iterates over loaded shared objects, and i guess involves a lock for if you load more objects while mappin
21:34:37
Bike
https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2-fde.c#L1029-L1102 here is... a definition, of unwind_find_FDE. don't know if it's the canonical one because of the preprocessing mess
21:34:56
drmeister
I took quite a few stack samples and observed synchronization in the dl_ operators, but there also appears to be some locking in Unwind_find_FDE itself. But I think the patch set is relevant to the issue.
21:37:17
drmeister
What does it take to activate that path? Compile and link with a different libgcc?
21:38:19
Bike
it's defined if (defined(__GTHREAD_MUTEX_INIT) || defined(__GTHREAD_MUTEX_INIT_FUNCTION)) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4)
21:43:11
Bike
also it might be compiled in but not succeding on that path, and so dropping back to the locks.
21:49:16
Bike
as you can see, it just tries the fast path, and then if it doesn't succeed it goes back to the locks
21:51:55
Bike
the comment kind of implies that there's an API for registering FDEs and that they're old?
21:52:12
Bike
"For targets where unwind info is usually not registered through theseAPIs anymore, avoid taking a global lock."
21:55:27
drmeister
Bike: Where do you see that ATOMIC_FDE_FAST_PATH is defined if (defined(__GTHREAD_MUTEX_INIT) || defined(__GTHREAD_MUTEX_INIT_FUNCTION)) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4)
21:55:29
Bike
naturally there's no coherent documentation that i can find. there's this i guess https://www.airs.com/blog/archives/460