https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to torvald from comment #15) > > Similarly, the 64 recursive locks in libc, again, significant amount of > > memory > > per process that doesn't care about exceptions, > > That might be reducable if we build custom locks and don't use pthread ones, > but we'll at least have 64b per lock. Right now the lock is I think 40 bytes per lock, which is 64 * 40 bytes per process. That is just too much (but of course the 64x locking a recursive lock is even worse). > > and especially signficiant > > slowdown on dlopen/dlclose. While some programs abuse exceptions for normal > > control flow, others abuse dlopen/dlclose. > > > > A rwlock ought to be better, but I don't think we have recursive rwlock in > > libc > > rdlock can be recursive, rwlock cannot. It is something we could add with > not much effort in a custom rwlock, I think. The dl_load_lock is I believe private, so it could use custom special rwlock. > > Plus the current rwlock > > implementation still takes uses a per-process lock to guard the inner > > operations > > on the rwlock, so while rwlock helps with longer critical sections, for very > > short ones it likely doesn't scale all that well. > > This will change as soon as my new rwlock is upstream. Especially short > rdlock sections will be much faster. Nice.
