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