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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10897 invoked from network); 17 Aug 2020 18:03:06 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 17 Aug 2020 18:03:06 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9CB7B9E194; Tue, 18 Aug 2020 04:03:00 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AC9539CAAF; Tue, 18 Aug 2020 04:02:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ewPwtnwq"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 55F779CAAF; Tue, 18 Aug 2020 04:02:22 +1000 (AEST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by minnie.tuhs.org (Postfix) with ESMTPS id BCC769C8BB for ; Tue, 18 Aug 2020 04:02:21 +1000 (AEST) Received: by mail-vs1-f47.google.com with SMTP id a127so1981749vsd.1 for ; Mon, 17 Aug 2020 11:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R99bNHhjWwbvQOAKGwMytOXinuXEzwco6YzcaN6bw6E=; b=ewPwtnwq2XkJf7kuohNBQJ2TY2sRCD5phZB4smjHl/fczaTNf4xuMnpaAbj/wBAxo7 M8CmSvilZLIABVQLD1OVs/u2lq8xOdWfOcWrLPnzIJMUb+JAs4ulB+VwD+MyH8p2nS/U s1Aw9Chkcj1G8SkpSZH+ciNSINrB5Fik3VyervSoZxmHRwbdVFqRRYrZiiohdRweoMd0 GXxhes0UFn6rW1NjUAM6k+odGmO+tWJuBXj3FIwHLK2jr7nEprryF/wHQKVA7OAxHOpH sQMqc6wxlZ0junSlSnpYgBys9Bznk2PzLO9W6tVy2SoTGSH/6NNG1F7FEPeTUJlNUMi1 oIhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R99bNHhjWwbvQOAKGwMytOXinuXEzwco6YzcaN6bw6E=; b=ARF/YRtMDfg3NJdWGIcC8A1YXesJ9q3//t5sePkyU2zoUYFcVHTp1imk4SuRDTTyqD gtVHGv+Et7dkvrBHeCkxCNgKt9SP+1Q7eTM32cDASHej4FTCPkU98vcGwscNStpQHm3p ijnQw3RNkIHuWxYjgroIxSISA4/R6YbdAcNjJP5aFwdWnQlW1oOu9ekhlRjNtGam60nI mGpvHJQxxyWHTzrwC18EOvuGwshGIuB69kHPNp2oWiIs/XuWERmfIewjw2WCZtO/ftBn 5evh4Wh7bvTU6R1HKqfKITFu7aPL5clpeZiikxZRfDlrxI6F/NVTEKPhsdnLRVAMPALn saLg== X-Gm-Message-State: AOAM531S8ztrSrjqjjt0UAEM8/fmHLQEtKDPsBin+/3Xr4E4MQOwmvru jlS1Tt9rIOF9x5AF3cD5WoFHgLDOGOQqcUZimkLRQLgJ X-Google-Smtp-Source: ABdhPJyxfh6Qv9IcrpB+wr9KJovCG1q8Va92rRwQL5kV5YE69h1M8g20X0axQ9w9rPDSw1f3Gn6xEhLgyZAK4igzjQg= X-Received: by 2002:a67:f116:: with SMTP id n22mr2411070vsk.228.1597687340820; Mon, 17 Aug 2020 11:02:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:48e9:0:0:0:0:0 with HTTP; Mon, 17 Aug 2020 11:02:20 -0700 (PDT) In-Reply-To: <20200817020224.104B518C095@mercury.lcs.mit.edu> References: <20200817020224.104B518C095@mercury.lcs.mit.edu> From: Paul Winalski Date: Mon, 17 Aug 2020 14:02:20 -0400 Message-ID: To: Noel Chiappa Content-Type: text/plain; charset="UTF-8" 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: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/16/20, Noel Chiappa wrote: > > The V7 compiler seems to use sbrk() (the system call to manage the location of > the end of a process' data space), and manage the additional data space > 'manually'; it does not seem to use a true generic heap. See gblock() in > c01.c: This is very common in compilers. Both the DEC/Compaq and Intel compilers manage heap memory this way. Each particular phase or pass of a compiler tends to build its on set of data structures in heap, and then free the whole mess when the phase/pass is done. malloc/free doesn't fit the model very well because you have to free each structure individually, and for more persistent structures you don't get very good locality of reference. What works better is to use a multitude of mini-heaps that can be freed up all in one go. -Paul W.