From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 9D63E385D0F2; Fri, 28 Oct 2022 12:31:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D63E385D0F2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52b.google.com with SMTP id m15so7604180edb.13; Fri, 28 Oct 2022 05:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2Y8N7LBST5utIesxusnTWy+1NRtpdNvuO/ShSHomuxo=; b=UGf+aSQk9cAbwlqFtbcW/AlN/aajZU/pGQQf9WiiEP/qWQ+ho6IJFMRjLwZ/CtXAqW sgtK8Hc3acZa2DEn+BrM7q0HwX9M9DEYCgBHigbTRBguWjVz5xVjLOkh4KvaD7HpqEO5 aoDrE5w1DslTpZ7z8GZyYo8z/lcX0GmP16iXjkeeSIxmbayYqVKr9X/eXGLaDR2zdW+r Lw9xl+yZVVbGcurGrFj+7JTtBJaejPHyqs7p8CWaOBn44HrljV7nSAVSWdjOm1nRY40N dVgMl6JBI+Yk3BBALtKwJ0e2eObsjMWebE+sgAwYNifwV40XOGnPIXBczwh7R0ELyx/j VkGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2Y8N7LBST5utIesxusnTWy+1NRtpdNvuO/ShSHomuxo=; b=rDQVHnDpH/xefV7FCJcAmqJJD1dD2Wk83OUPdHEi7ReVCod8e0sM5tQfhUuUDGo6Ro IhJVGFb9De+7HZ5bC3W4BRm+mUrYvuLcBJC1QPWG4UvHVIPreyhsNhHyh9KVZWpa374L mSoJOn22cUViGy5jU4prt56vsI5we0OJO/NdewKQVTfp0Y6ImIP1OXR5ySVWsRZT98UY 1wEEQ68Ktgm3vw5jPWkQclKJBRxt7Va2Pe9mxPV1eIIpHM+vd3YLutBotaYg+LQS8lbQ 59SdKIB5faamJrHgZKZA5Y/Lyp9XmV+4YF8CJ2+mHss8njyhLskwwAL5/om5iTQxuaIY A+5A== X-Gm-Message-State: ACrzQf3jB3LvS3A+bw9OZJqqCh8lE4eEySIIvGV82iHWB8Q2JcGv84mM hlRan+dy9Ms3K1ZWZ6Zzt/YZCQBiJwqtMgTBYcc= X-Google-Smtp-Source: AMsMyM7no73gspWeNy5QWKXmi6bpGPN8H5DfhirOsGH/Nhch9417mvOLIq3mT7hDUeeMvF337L3FEyB6D5aZsix1c2Y= X-Received: by 2002:a05:6402:3509:b0:45d:c25b:b80e with SMTP id b9-20020a056402350900b0045dc25bb80emr50884419edd.250.1666960318143; Fri, 28 Oct 2022 05:31:58 -0700 (PDT) MIME-Version: 1.0 References: <20221026081811.602573-1-arthur.cohen@embecosm.com> <65f8a9e4-68ae-9f43-c5c7-32dde62a14c3@embecosm.com> In-Reply-To: <65f8a9e4-68ae-9f43-c5c7-32dde62a14c3@embecosm.com> From: Richard Biener Date: Fri, 28 Oct 2022 14:31:46 +0200 Message-ID: Subject: Re: Rust frontend patches v3 To: Arthur Cohen Cc: David Malcolm , gcc-patches@gcc.gnu.org, gcc-rust@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Oct 28, 2022 at 1:45 PM Arthur Cohen wrote: > > Hi David, > > On 10/26/22 23:15, David Malcolm wrote: > > On Wed, 2022-10-26 at 10:17 +0200, arthur.cohen@embecosm.com wrote: > >> This is the fixed version of our previous patch set for gccrs - We've > >> adressed > >> the comments raised in our previous emails. > > > > [...snip...] > > > > (Caveat: I'm not a global reviewer) > > > > Sorry if this is answered in the docs in the patch kit, but a high- > > level question: what's the interaction between gccrs and gcc's garbage > > collector? Are the only GC-managed objects (such as trees) either (a) > > created near the end of the gccrs, or (b) common globals created at > > initialization and with GTY roots? > > We only create trees at the last point of our compilation pipeline, > before directly writing them to the backend. This then calls a > `write_global_definitions` method, that we ported over directly from the > Go frontend. Among other things, this method has the role of preserving > trees from the GC using `go_preserve_from_gc()` (or > `rust_preserve_from_gc()` in our case). > > Elsewhere in our pipeline, we never call any garbage-collection routines > or GC-related functions. > > > Are there any points where a collection happen within gccrs? Or is almost everything stored using > > gccrs's own data structures, and are these managed in the regular (non- > > GC) heap? > > This is correct. We have an AST representation, implemented using unique > pointers, which is then lowered to an HIR, also using unique pointers. > > > I skimmed the patches and see that gccrs uses e.g. std::vector, > > std::unique_ptr, std::map, and std::string; this seems reasonable to > > me, but it got me thinking about memory management strategies. > > > > I see various std::map e.g. in Rust::Compile::Context; so e.g. > > is the GC guaranteed never to collect whilst this is live? > > This is a really interesting question, and I hope the answer is yes! But > I'm unsure as to how to enforce that, as I am not too familiar with the > GCC GC. I'm hoping someone else will weigh in. As I said, we do not do > anything particular with the GC during the execution of our > `CompileCrate` visitor, so hopefully it shouldn't run. collection points are explicit, but some might be hidden behind middle-end APIs, in particular once you call cgraph::finalize_compilation_unit you should probably expect collection. Richard. > > Hope this is constructive > > Dave > > > > Thanks a lot for the input, > > All the best, > > Arthur > > > >