From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B92863857C5E for ; Fri, 28 Oct 2022 13:06:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B92863857C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666962389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cs5YsTu+PD12k0gC7dBJQMojo+IKLxsii2vwAFPb5Us=; b=e01n9SSQ3F6LCBZ0FSCGYcXHddN2jEA8OFkOWYeOL2EA0r0BVm4P5FtHMYGpm4M3VF06n3 HZhAPAclElOBH5Jsc4k5SSxezosjHNCT3IsXHJDMZjqkKeT068NRhyN6t/phZvCx0h8FxD v7wqjqYmEHmPWdbDGfGMZrpzexpwc8Y= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-403-FOygsV5lMAOiVd0vKV6WnA-1; Fri, 28 Oct 2022 09:06:28 -0400 X-MC-Unique: FOygsV5lMAOiVd0vKV6WnA-1 Received: by mail-qv1-f71.google.com with SMTP id q5-20020ad44025000000b004bb76ca694bso2865404qvp.18 for ; Fri, 28 Oct 2022 06:06:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cs5YsTu+PD12k0gC7dBJQMojo+IKLxsii2vwAFPb5Us=; b=5mbg0XFLRmq/yPuzMpCHx82GBOzLRAxKnDvsiwdn4lpRz1+svdxjtLgDslZoJ5ez1K jMQaKG2vQyOhd358Qtbnbz8Bp9vkCOsKDoJY+pffYramI9MVSZI4/FLyJDHBkL2aElLv hYLT0Wt/V4H00mkvMuMyzKD9pr/E2cQXmcjGQIGw+jyUJ0c58ABZ7YydPznFgCJEy+9b C5PHAh6BN8KIQlITUjtQO87ICeK7J21zdvtUoi1VcqKlB7LFGkzih2WHeTLOaB/K3jc3 4H4YNdrSJoCoB9oPNztNg+3OZubVob0X9v2XEUCOVnJ+IdQpr7rFCzlT5tTRygmanLJd zvzA== X-Gm-Message-State: ACrzQf3xosIL9z1lI+xLdeEqnkFtxcoGFc1zOilMO1fzOSuE1EYZIGDm Np49MzBp0vfGfm2E4lmcbSTCjUkS6+hPaUZ88pZLU/kT+4gqWYYAvtzFJ5lfN++d93yA08GXXDW K1SBWu8zVZQiEfg== X-Received: by 2002:ac8:7f8c:0:b0:39c:db49:29cc with SMTP id z12-20020ac87f8c000000b0039cdb4929ccmr45634041qtj.224.1666962387427; Fri, 28 Oct 2022 06:06:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7wRx5fmGWDLEw7K7bcyJkcCaKLRsrtzLhTBsySdCFbE4Qf5hn1nClzPnRjoVrXuy4PjNdHyg== X-Received: by 2002:ac8:7f8c:0:b0:39c:db49:29cc with SMTP id z12-20020ac87f8c000000b0039cdb4929ccmr45634015qtj.224.1666962387149; Fri, 28 Oct 2022 06:06:27 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id bi19-20020a05620a319300b006eeca296c00sm2930546qkb.104.2022.10.28.06.06.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 06:06:26 -0700 (PDT) Message-ID: Subject: Re: Rust frontend patches v3 From: David Malcolm To: Arthur Cohen , gcc-patches@gcc.gnu.org Cc: gcc-rust@gcc.gnu.org Date: Fri, 28 Oct 2022 09:06:25 -0400 In-Reply-To: <65f8a9e4-68ae-9f43-c5c7-32dde62a14c3@embecosm.com> References: <20221026081811.602573-1-arthur.cohen@embecosm.com> <65f8a9e4-68ae-9f43-c5c7-32dde62a14c3@embecosm.com> User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham 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, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote: > Hi David, >=20 > On 10/26/22 23:15, David Malcolm wrote: > > On Wed, 2022-10-26 at 10:17 +0200, arthur.cohen@embecosm.com=C2=A0wrote= : > > > This is the fixed version of our previous patch set for gccrs - > > > We've > > > adressed > > > the comments raised in our previous emails. > >=20 > > [...snip...] > >=20 > > (Caveat: I'm not a global reviewer) > >=20 > > 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?=C2=A0 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?=20 >=20 > We only create trees at the last point of our compilation pipeline,=20 > before directly writing them to the backend. This then calls a=20 > `write_global_definitions` method, that we ported over directly from > the=20 > Go frontend. Among other things, this method has the role of > preserving=20 > trees from the GC using `go_preserve_from_gc()` (or=20 > `rust_preserve_from_gc()` in our case). >=20 > Elsewhere in our pipeline, we never call any garbage-collection > routines=20 > or GC-related functions. >=20 > > Are there any points where a collection happen within gccrs?=C2=A0 Or i= s > > almost everything stored using > > gccrs's own data structures, and are these managed in the regular > > (non- > > GC) heap? >=20 > This is correct. We have an AST representation, implemented using > unique=20 > pointers, which is then lowered to an HIR, also using unique > pointers. >=20 > > 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. > >=20 > > 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? >=20 > This is a really interesting question, and I hope the answer is yes! > But=20 > I'm unsure as to how to enforce that, as I am not too familiar with > the=20 > GCC GC. I'm hoping someone else will weigh in. As I said, we do not > do=20 > anything particular with the GC during the execution of our=20 > `CompileCrate` visitor, so hopefully it shouldn't run. I'm guessing that almost all of gccrs testing so far has been on relatively small examples, so that even if the GC considers collecting, the memory usage might not have exceeded the threshold for actually doing the mark-and-sweep collection, and so no collection has been happening during your testing. In case you haven't tried yet, you might want to try adding: --param=3Dggc-min-expand=3D0 --param=3Dggc-min-heapsize=3D0 which IIRC forces the GC to actually do its mark-and-sweep collection at every potential point where it might collect. I use these params in libgccjit's test suite; it massively slows things down, but it makes any GC misuse crash immediately even on minimal test cases, rather than hiding problems until you have a big (and thus nasty) test case. Hope this is helpful Dave >=20 > > Hope this is constructive > > Dave > >=20 >=20 > Thanks a lot for the input, >=20 > All the best, >=20 > Arthur >=20 >=20 >=20 >=20