freenode/#clasp - IRC Chatlog
Search
13:59:43
kpoeck
beach quicklisp takes flexichain from https://common-lisp.net/project/flexichain/download/flexichain_latest.tgz
14:00:02
kpoeck
See https://github.com/quicklisp/quicklisp-projects/blob/master/projects/flexichain/source.txt
14:01:29
kpoeck
or should the source for quicklisp be switched to https://github.com/robert-strandh/Flexichain ?
14:21:14
kpoeck
So cold a ask Zach for quicklisp to switch to https://github.com/robert-strandh/Flexichain ?
14:34:34
kpoeck
Just quicklisp does not get it sources for flexichain from https://github.com/robert-strandh/Flexichain
14:35:29
kpoeck
Took me some time to find out, obviously for every project one can configure where source are coming from, for flexichain this is configure in https://github.com/quicklisp/quicklisp-projects/blob/master/projects/flexichain/source.txt
14:37:53
kpoeck
and loading mcclim I saw a message No support for weak pointers in this implementation. Things may get big and slow.
14:40:38
kpoeck
frgo put clasp definitions for clasp in https://github.com/trivial-garbage/trivial-garbage/blob/master/trivial-garbage.lisp#L126 and following
14:51:22
Bike
i'll have to look over all these portability libraries and make sure everything's exported from ext
14:54:34
kpoeck
Did create and quicklisp issue to change the source for flexichain https://github.com/quicklisp/quicklisp-projects/issues/1804
14:57:46
drmeister
Bike: can we bypass unwind_find_fde? Otherwise we run into the same contention problem don’t we?
15:07:44
Bike
based on the sources there's code paths where it uses atomic operations instead of locks. maybe we can figure out how to do that.
15:21:03
drmeister
I know people in the llvm community that might answer questions about exception handling implementation on Linux. Gather questions and we can ask them.
15:23:44
Bike
i don't know that i have any questions. it seems likely to me that they use locks because C++ code has never had this problem before
15:26:01
Bike
i mean i might have questions about exception handling more generally in the course of making the custom personality work, but that's different
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