From patchwork Thu Sep 10 14:44:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Wakely X-Patchwork-Id: 1361623 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=caZsBXI4; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4BnM9Q17msz9sPB for ; Fri, 11 Sep 2020 00:44:42 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ECFC838618AF; Thu, 10 Sep 2020 14:44:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECFC838618AF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1599749078; bh=LmY2dUcCKyzZxHR8e4pxvwmCgsn68kmAaUTCjKjYSHU=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=caZsBXI48mvmtS2RSy88ykwNVg3pgDJeS4s5jLTh16gjpk9XEeazpf94RdGkUSDn9 2tr1oPCAgfLJGFzNDfe5bkDTeGFc1BbGLrM8k8o92Cxpt06nNKdUCa8SeuDtexdiNL oC5MDmy47TVeohlMhKV0u/zjHOF7e2al7H3/OINc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id E38053860C3A for ; Thu, 10 Sep 2020 14:44:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E38053860C3A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-553-ZfNgL6nvNVaDMzI7qjmiYg-1; Thu, 10 Sep 2020 10:44:32 -0400 X-MC-Unique: ZfNgL6nvNVaDMzI7qjmiYg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8EC678DEC86; Thu, 10 Sep 2020 14:44:31 +0000 (UTC) Received: from localhost (unknown [10.33.37.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3BA922854C; Thu, 10 Sep 2020 14:44:31 +0000 (UTC) Date: Thu, 10 Sep 2020 15:44:30 +0100 To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [committed 2/2] libstdc++: handle small max_blocks_per_chunk in pool resources [PR 94160] Message-ID: <20200910144430.GA6061@redhat.com> References: <20200910144247.GA8265@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200910144247.GA8265@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jonathan Wakely via Gcc-patches From: Jonathan Wakely Reply-To: Jonathan Wakely Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" 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. Tested powerpc64le-linux. Committed to trunk. commit 30b41cfbb2dade63e52465234a725d1d02fe70aa Author: Jonathan Wakely Date: Thu Sep 10 15:39:15 2020 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. diff --git a/libstdc++-v3/src/c++17/memory_resource.cc b/libstdc++-v3/src/c++17/memory_resource.cc index 392d72ef32d..c04ea6a5da4 100644 --- a/libstdc++-v3/src/c++17/memory_resource.cc +++ b/libstdc++-v3/src/c++17/memory_resource.cc @@ -898,7 +898,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 + = aligned_ceil(opts.max_blocks_per_chunk, 4); + } + else + { + // round down + opts.max_blocks_per_chunk &= ~size_t(3); + } } if (opts.max_blocks_per_chunk > chunk::max_blocks_per_chunk()) @@ -1039,11 +1050,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 2775e1260ea..526b7ede13a 100644 --- a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc +++ b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc @@ -300,6 +300,25 @@ test07() } } +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() { @@ -310,4 +329,5 @@ main() test05(); test06(); test07(); + test08(); }