From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29809 invoked by alias); 9 Mar 2019 17:23:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29736 invoked by uid 89); 9 Mar 2019 17:23:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=chose, worker, readily, largest X-HELO: gateway22.websitewelcome.com Received: from gateway22.websitewelcome.com (HELO gateway22.websitewelcome.com) (192.185.47.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 09 Mar 2019 17:23:06 +0000 Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 160EF6091 for ; Sat, 9 Mar 2019 11:23:04 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 2fgchlfGRdnCe2fgchg3sR; Sat, 09 Mar 2019 11:23:04 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc:MIME-Version :Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ur4IZwiLBrcVqp0Ebh0/LNx99wwth/Q/EOryC3qsImA=; b=mBz+IJFAO3H8HUcE74znVprQsM +2jY/fKwlBT0bAftUZBCUg9lrzKRLP2bIUVKD3oiRDyvCcd5hWoGkmLZKOUsEYhqeijUHmBCsUa6T iVPQDy69L4wKYfLZ1wrJdhEY6; Received: from 75-166-85-218.hlrn.qwest.net ([75.166.85.218]:56494 helo=bapiya.Home) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h2fgc-003et2-BT for gdb-patches@sourceware.org; Sat, 09 Mar 2019 11:23:02 -0600 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [RFC 0/6] Demangle minimal symbol names in worker threads Date: Sat, 09 Mar 2019 17:23:00 -0000 Message-Id: <20190309172300.2764-1-tom@tromey.com> X-SW-Source: 2019-03/txt/msg00211.txt.bz2 I've thought for a while that gdb should take advantage of multiple cores in order to speed up its processing. This series is some initial work in that direction. In particular, this patch arranges to do the demangling for minimal symbols in worker threads. I chose this because it seemed relatively simple to reason about, as the demangler is already mostly thread-safe (except, as it turns out, the Ada demangler, which is fixed in this series). It isn't actually a very important thing to speed up, as minimal symbol reading is already reasonably speedy; but I thought it best to start with something straightforward to facilitate flushing out thread safety bugs. That said, this does yield a modest speedup on the largest .so on my system: A typical pre-patch run looks like: /bin/time ./gdb -nx --batch --data-directory ./data-directory/ /usr/lib64/firefox/libxul.so 1.22user 0.21system 0:01.46elapsed 98%CPU (0avgtext+0avgdata 188204maxresident)k And with the patches: 1.47user 0.39system 0:01.11elapsed 167%CPU (0avgtext+0avgdata 206380maxresident)k I've only seen %CPU up to 185% or so; but since this is a 4-core machine I suppose that means there are still gains to be had somewhere? This implementation adds a lock to the demangled hash table code. I tried a different implementation which did not add locking here. In that implementation, minsym names were simply not entered into the hash table and thus not shared. However, the lock turned out to be no slower, and I believe the hash table saves some memory, so I decided on this approach. One possible enhancement in this area would be call build_minimal_symbol_hash_tables in a background thread. This is trickier than it sounds, though. First, it would require more locking, so that gdb would not attempt to use the minsym hash tables before they were constructed. Second, it is possible to introduce races where the objfile is deleted while the worker thread is still running. I have some more ideas for areas in gdb that could benefit from threads. I'm happy to discuss if you're interested. Because threads are tricky, I think this requires some extra scrutiny. Also I've done various tests using helgrind, which pointed out some of the things fixed in this series. You can't readily apply this, because it depends on both the cleanup removal series and the minsym improvement series. However it is in my github repository on the branch "t/parallel-minsyms-mutex". Tested by the buildbot. Tom