public inbox for libstdc++-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org
Subject: [gcc r10-8780] libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160]
Date: Mon, 21 Sep 2020 20:18:06 +0000 (GMT)	[thread overview]
Message-ID: <20200921201806.7A8433857C40@sourceware.org> (raw)

https://gcc.gnu.org/g:9ae110d4f8edd61cf56ee5fea62cadc8e781e8dc

commit r10-8780-g9ae110d4f8edd61cf56ee5fea62cadc8e781e8dc
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Sep 10 15:39:15 2020 +0100

    libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160]
    
    When a pool resource is constructed with max_blocks_per_chunk=1 it ends
    up creating a pool with blocks_per_chunk=0 which means it never
    allocates anything. Instead it returns null pointers, which should be
    impossible.
    
    To avoid this problem, round the max_blocks_per_chunk value to a
    multiple of four, so it's never smaller than four.
    
    libstdc++-v3/ChangeLog:
    
            PR libstdc++/94160
            * src/c++17/memory_resource.cc (munge_options): Round
            max_blocks_per_chunk to a multiple of four.
            (__pool_resource::_M_alloc_pools()): Simplify slightly.
            * testsuite/20_util/unsynchronized_pool_resource/allocate.cc:
            Check that valid pointers are returned when small values are
            used for max_blocks_per_chunk.
    
    (cherry picked from commit 30b41cfbb2dade63e52465234a725d1d02fe70aa)

Diff:
---
 libstdc++-v3/src/c++17/memory_resource.cc           | 21 +++++++++++++++------
 .../unsynchronized_pool_resource/allocate.cc        | 20 ++++++++++++++++++++
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/libstdc++-v3/src/c++17/memory_resource.cc b/libstdc++-v3/src/c++17/memory_resource.cc
index 95352b23537..75ae24e0a06 100644
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -873,7 +873,18 @@ namespace pmr
       }
     else
       {
-	// TODO round to preferred granularity ?
+	// Round to preferred granularity.
+	if (opts.max_blocks_per_chunk < size_t(-4))
+	  {
+	    // round up
+	    opts.max_blocks_per_chunk += 3;
+	    opts.max_blocks_per_chunk &= ~size_t(3);
+	  }
+	else
+	  {
+	    // round down
+	    opts.max_blocks_per_chunk &= ~size_t(3);
+	  }
       }
 
     if (opts.max_blocks_per_chunk > chunk::max_blocks_per_chunk())
@@ -1013,11 +1024,9 @@ namespace pmr
 	  : pool_sizes[i];
 
 	// Decide on initial number of blocks per chunk.
-	// Always have at least 16 blocks per chunk:
-	const size_t min_blocks_per_chunk = 16;
-	// But for smaller blocks, use a larger initial size:
-	size_t blocks_per_chunk
-	  = std::max(1024 / block_size, min_blocks_per_chunk);
+	// At least 16 blocks per chunk seems reasonable,
+	// more for smaller blocks:
+	size_t blocks_per_chunk = std::max(size_t(16), 1024 / block_size);
 	// But don't exceed the requested max_blocks_per_chunk:
 	blocks_per_chunk
 	  = std::min(blocks_per_chunk, _M_opts.max_blocks_per_chunk);
diff --git a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
index 5bf20cf262c..ef5f921211d 100644
--- a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
+++ b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
@@ -239,6 +239,25 @@ test06()
   }
 }
 
+void
+test08()
+{
+  std::pmr::pool_options opts;
+  opts.largest_required_pool_block = 64;
+
+  // PR libstdc++/94160
+  // max_blocks_per_chunk=1 causes pool resources to return null pointers
+  for (int i = 0; i < 8; ++i)
+  {
+    opts.max_blocks_per_chunk = i;
+    std::pmr::unsynchronized_pool_resource upr(opts);
+    auto* p = (int*)upr.allocate(4);
+    VERIFY( p != nullptr );
+    *p = i;
+    upr.deallocate(p, 4);
+  }
+}
+
 int
 main()
 {
@@ -248,4 +267,5 @@ main()
   test04();
   test05();
   test06();
+  test08();
 }


                 reply	other threads:[~2020-09-21 20:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20200921201806.7A8433857C40@sourceware.org \
    --to=redi@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    --cc=libstdc++-cvs@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).