From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21127 invoked from network); 17 Aug 2020 19:36:18 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 17 Aug 2020 19:36:18 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 042DE9E185; Tue, 18 Aug 2020 05:36:15 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 931AE9CAB3; Tue, 18 Aug 2020 05:36:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="fJHGTq7t"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6FB369CAB3; Tue, 18 Aug 2020 05:36:00 +1000 (AEST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by minnie.tuhs.org (Postfix) with ESMTPS id AA6AB9C8BB for ; Tue, 18 Aug 2020 05:35:59 +1000 (AEST) Received: by mail-wr1-f42.google.com with SMTP id r15so6169229wrp.13 for ; Mon, 17 Aug 2020 12:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nCUC0Yd8Foy9/eY6y2KvpweA5vohxNIq1JGkw5IZ0Hc=; b=fJHGTq7tomcLSq0GP+KcxtBPIxEZvsDNSMPKo4hVyI2/oAmI+l/953PjM9vPuglgjs u54YW3AMM+5ivtTM7YmsIMuDOT3FPxCTpAlyQMTOTGQbNdsR7uOvwFKbZz0zba/IP1bM T0YEGXSPB8rPajcCZU3unlX/1ahQFraOMkwIBfQqU1ulvxbAVnMHL394vygGi1Yd24a8 v7xuOpLxSgO+K+ycpm47xs24sgU0WnyYQjTDwIweAzgMcx4+QEta4Z/dD482BTlPE7Zx kWlb4UD2GTU2TiBdILlDmvtkIvmIV5SYLGQOrGpvqzSmG9tIOO/nwz+S/WFJXP1tVNui mAtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nCUC0Yd8Foy9/eY6y2KvpweA5vohxNIq1JGkw5IZ0Hc=; b=aeLuFcZn0racsJzLEGHyJ3yihcgBR6CADY3AQInDX/YG0ZsvAIBQq2DJXLu0+n89gG A7egdUaPap8rQhVYCLXSC0kZdMDEIQ3E+deJPhCOmwB0MYbQsYoXtv4NBEP9FoQknApR wlBh+g/ooYftXoa+qufpicoYfBvjVd1qqUQ3V/yyqpz4Lr3p9mxJ9p04K77Lec59BDWA 95u/S0WiARDXJ3tpusUK22hUfuBGKK694OunPTP8CMb0tuQug/quOCJEypC9p+Hr4u0W Pjdebj4ZwKQ4Jn4oP+MBwR3pBD4vU8T8s0d/MYcEa8e/zxU7bJBHKRv/Hh6I/xEk8IMZ eCww== X-Gm-Message-State: AOAM530TJPtFTM0hirkFiy/PIcGEGQ/bRUVR2sCQ5Ff8CldOWh5F4Opo aQ+QUFoEMpbNTWTdWlZpx8DX1Mw4nVSVgrZtE/2LV5KIGQ4GTQ== X-Google-Smtp-Source: ABdhPJwHMbRHqIPW9m86ToRXkohlwC9UPC4/enljMQ2+dpgfwZ1gmXRTzMITmlpY+HcOnU5zd0mniOH9cAiOxDFdhtk= X-Received: by 2002:a5d:4a8a:: with SMTP id o10mr16057465wrq.327.1597692958391; Mon, 17 Aug 2020 12:35:58 -0700 (PDT) MIME-Version: 1.0 References: <20200817020224.104B518C095@mercury.lcs.mit.edu> In-Reply-To: From: Jim Geist Date: Mon, 17 Aug 2020 15:35:47 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000003ec23405ad17e103" Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , Noel Chiappa Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003ec23405ad17e103 Content-Type: text/plain; charset="UTF-8" True, but zones and HeapAlloc do a fair bit of work to handle objects of multiple sizes. If you're partitioning up a page and you know every object on the page is 8 or 16 or 48 bytes, it's MUCH simpler. And a lot of the data structures in a compiler tend to be small-tens-of-bytes nodes. On Mon, Aug 17, 2020 at 3:28 PM Paul Winalski wrote: > On 8/17/20, Jim Geist wrote: > > When did mmap(2) come about? Another thing I've seen is building a small > > block allocator on top of that. You can guarantee that all your objects > are > > nicely collected into the same set of pages for locality with very little > > overhead. > > > mmap(2) certainly can be used to allocate blocks for the mini-heap > itself, but you still have to write your own equivalents of malloc() > and free() to allocate data structures within the mini-heap. The nice > thing about VMS heap zones and Microsoft's private heaps is that you > get the malloc()/free() layer off-the-shelf; you don't have to roll > your own. > > -Paul W. > --0000000000003ec23405ad17e103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
True, but zones and HeapAlloc do a fair bit of work to han= dle objects of multiple sizes. If you're partitioning=C2=A0up a page an= d you know every object on the page is 8 or 16 or 48 bytes, it's MUCH s= impler. And a lot of the data structures in a compiler tend to be small-ten= s-of-bytes nodes.

On Mon, Aug 17, 2020 at 3:28 PM Paul Winalski <paul.winalski@gmail.com> wrot= e:
On 8/17/20, J= im Geist <vel= ocityboy@gmail.com> wrote:
> When did mmap(2) come about? Another thing I've seen is building a= small
> block allocator on top of that. You can guarantee that all your object= s are
> nicely collected into the same set of pages for locality with very lit= tle
> overhead.
>
mmap(2) certainly can be used to allocate blocks for the mini-heap
itself, but you still have to write your own equivalents of malloc()
and free() to allocate data structures within the mini-heap.=C2=A0 The nice=
thing about VMS heap zones and Microsoft's private heaps is that you get the malloc()/free() layer off-the-shelf; you don't have to roll
your own.

-Paul W.
--0000000000003ec23405ad17e103--