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


             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: link
Be 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).