From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4B2611F4B4 for ; Mon, 18 Jan 2021 08:17:37 +0000 (UTC) Received: from localhost ([::1]:50762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1PjE-0004sY-7j for normalperson@yhbt.net; Mon, 18 Jan 2021 03:17:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1PjB-0004sF-Mb for bug-gnulib@gnu.org; Mon, 18 Jan 2021 03:17:33 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]:31798) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1Pj9-0000KX-Ny; Mon, 18 Jan 2021 03:17:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610957849; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:From: Subject:Sender; bh=dJedkbuJwtlr89UtutJADajWJN3hPIekTSL2hGlemw0=; b=Nwq/+V+qyOwYq0lO3rj+Lh9S5ydcttgFkUp8xDnL7oW5r9eSUkm/wXzA8ZO8buBlXS /ZmfM93Xvbl98uwHK4dxXsvzpnauN11vq1Rs7DtH2aMuXYc2yA43g/9xDc43hiOji0lE bqdR//0tV7wNl3ThsdVzw3k58wR9thwvuy0XU+gC9TqPhRinBloMW/FqKgf/0u98SAPT ssbFM/773vDk7eFh+R8XrqZpJloFFTFW0zE2vhAcrW1z1aRBKLiimnGstIiKOfNalhlV r9oQBbR5W5xzFvA+zZfRW2lPzrA/1TMAyqLJszR5A+8hhwr8mE2PEi2n/st3pahPjCSu +7Bg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyvs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id u0aa20x0I8HSsqp (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Mon, 18 Jan 2021 09:17:28 +0100 (CET) From: Bruno Haible To: Tim =?ISO-8859-1?Q?R=FChsen?= Subject: Re: immutable string type Date: Mon, 18 Jan 2021 09:17:27 +0100 Message-ID: <9423806.pBvWCk5liC@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <238f4446-9fb6-363e-9277-6fb1bbad10cf@gmx.de> References: <2299371.vStytN2T3e@omega> <2241193.CIXnYTY7CS@omega> <238f4446-9fb6-363e-9277-6fb1bbad10cf@gmx.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Received-SPF: none client-ip=81.169.146.162; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.252, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, Darshit Shah Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Tim R=FChsen wrote on 2019-12-29: > >> As a more general approach, a function that switches already allocated > >> memory into read-only memory would be handy. Like in > >> - m =3D malloc() > >> - initialize m with some data > >> - if in debug mode: call memmap_readonly(m) - from this point on 'm' = is > >> read-only and a write leads to a segmentation fault. > >> - ... > >> - free(m) > >=20 > > Hardware has write barriers only on the page level. You can't easily re= quest > > a write barrier for a requence of, say, 30 bytes. To accomodate this, t= he > > API needs to have a certain shape. Paul wrote: >=20 > True, and it means that immalloc() always allocate multiples of the page > size (page is 4096 bytes on x86_64 ?). How do you plan to optimize > memory usage here ? I optimized the memory usage by allocated several small or medium sized obj= ects in a single memory page. Through the module 'ssfmalloc'. Bruno