From: Nicholas Nethercote <njn@valgrind.org>
Date: Tue, 16 Oct 2007 23:18:06 +0000 (+0000)
Subject: Add a comment.
X-Git-Tag: svn/VALGRIND_3_3_0~193
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cd95227e38e689b43a5b9e26f9110fc970f1f043;p=thirdparty%2Fvalgrind.git

Add a comment.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7009
---

diff --git a/coregrind/m_mallocfree.c b/coregrind/m_mallocfree.c
index 131d179d09..d1b18c4121 100644
--- a/coregrind/m_mallocfree.c
+++ b/coregrind/m_mallocfree.c
@@ -1104,6 +1104,24 @@ void* VG_(arena_malloc) ( ArenaId aid, SizeT req_pszB )
    req_bszB = pszB_to_bszB(a, req_pszB);
 
    // Scan through all the big-enough freelists for a block.
+   //
+   // Nb: this scanning might be expensive in some cases.  Eg. if you
+   // allocate lots of small objects without freeing them, but no
+   // medium-sized objects, it will repeatedly scanning through the whole
+   // list, and each time not find any free blocks until the last element.
+   //
+   // If this becomes a noticeable problem... the loop answers the question
+   // "where is the first nonempty list above me?"  And most of the time,
+   // you ask the same question and get the same answer.  So it would be
+   // good to somehow cache the results of previous searches.
+   // One possibility is an array (with N_MALLOC_LISTS elements) of
+   // shortcuts.  shortcut[i] would give the index number of the nearest
+   // larger list above list i which is non-empty.  Then this loop isn't
+   // necessary.  However, we'd have to modify some section [ .. i-1] of the
+   // shortcut array every time a list [i] changes from empty to nonempty or
+   // back.  This would require care to avoid pathological worst-case
+   // behaviour.
+   //
    for (lno = pszB_to_listNo(req_pszB); lno < N_MALLOC_LISTS; lno++) {
       b = a->freelist[lno];
       if (NULL == b) continue;   // If this list is empty, try the next one.