public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "peturr02 at ru dot is" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/16614] New: Excessive resource usage in __mt_alloc Date: Sun, 18 Jul 2004 12:32:00 -0000 [thread overview] Message-ID: <20040718123236.16614.peturr02@ru.is> (raw) In include/ext/mt_allocator.h: template<typename _Tp> class __mt_alloc { [...] struct _Thread_record { // Points to next free thread id record. NULL if last record in list. _Thread_record* volatile _M_next; // Thread id ranging from 1 to _S_max_threads. size_t _M_id; }; [...] if (__gthread_active_p()) { const size_t __k = sizeof(_Thread_record) * _S_options._M_max_threads; __v = ::operator new(__k); [...] // Initialize per thread key to hold pointer to // _S_thread_freelist. __gthread_key_create(&_S_thread_key, _S_destroy_thread_key); The problem: This happens in the template __mt_alloc<_Tp>, so this code gets run for each type for which __mt_alloc is instantiated. The default value of _M_max_threads is 4096 and sizeof(_Thread_record) is 8 (on 32-bit systems) so that means 32k per type. For a large program that can easily mean several hundred megabytes. The use of __gthread_key_create is even worse; there is only a limited number of available keys for each program, so this places a hard upper limit on the number of types that can be used with __mt_alloc. It also limits the number of keys available for other purposes. The return value of __gthread_key_create should be checked, since it may fail. There doesn't seem to be any benefit to having _Thread_record depend on the template parameter, it didn't do so until this change: 2003-12-23 Benjamin Kosnik <bkoz@redhat.com> * include/ext/new_allocator.h (new_allocator): Proper allocator class. (__new_alloc): Delete. * include/ext/malloc_allocator.h (malloc_allocator): Same. (__malloc_alloc): Delete. * include/ext/mt_allocator.h: Same, but weakly. * include/ext/debug_allocator.h: Convert to the new style. * include/ext/pool_allocator.h: Use global new and delete directly. * include/backward/alloc.h: Don't inject malloc_allocator, or debug_allocator. * testsuite/ext/allocators.cc: Minimal fixups for usage of new classes. Comment out tests with __pool_alloc for now. * testsuite/performance/allocator.cc: Same. It seems that none of the other nested types or static members need the template parameter either, and indeed most of the code seems to assume that there will be only one copy of the static members (for example, a bucket of chunks of size 8 will be created for all types, but this bucket will never be used if sizeof(_Tp) > 8). -- Summary: Excessive resource usage in __mt_alloc Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peturr02 at ru dot is CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16614
next reply other threads:[~2004-07-18 12:32 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-07-18 12:32 peturr02 at ru dot is [this message] 2004-07-18 12:46 ` [Bug libstdc++/16614] " peturr02 at ru dot is 2004-07-19 23:17 ` bkoz at gcc dot gnu dot org 2004-07-22 3:33 ` bkoz at gcc dot gnu dot org 2004-07-22 3:35 ` bkoz at gcc dot gnu dot org 2004-09-01 22:17 ` cvs-commit at gcc dot gnu dot org 2004-09-03 16:07 ` bkoz at gcc dot gnu dot org 2004-10-11 20:27 ` cvs-commit at gcc dot gnu dot org 2004-10-28 21:54 ` bkoz at gcc dot gnu dot org 2004-10-28 21:56 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040718123236.16614.peturr02@ru.is \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).