This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcc/71744] Concurrently throwing exceptions is not scalable
- From: "gleb at scylladb dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 14 Sep 2016 11:04:35 +0000
- Subject: [Bug libgcc/71744] Concurrently throwing exceptions is not scalable
- Auto-submitted: auto-generated
- References: <bug-71744-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #19 from Gleb Natapov <gleb at scylladb dot com> ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Gleb Natapov from comment #16)
> > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > Allocate per thread storage dynamically somehow?
>
> If we want to use TLS (which I hope we don't), then e.g. a single __thread
> pointer with some registered destructor that would free it on process exit
> could do the job, and on the first exception it would try to allocate memory
> for the cache and other stuff and use that (otherwise, if memory allocation
> fails, just take a lock and be non-scalable).
>
I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do the
same here?
>
> Another alternative, perhaps much better, if Torvald is going to improve
> rwlocks sufficiently, would be to use rwlock to guard writes to the cache
> etc. too, and perhaps somewhat enlarge the cache (either statically, or
> allow extending it through allocation).
> I'd expect that usually these apps that use exceptions too much only care
> about a couple of shared libraries, so writes to the cache ought to be rare.
>
As I said in my previous reply, I tested the new rwlock and in congested case
it still slows does the system significantly, not the implementation fault, cpu
just does not like locked instruction much. Not having a lock will be
significantly better.