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.133.124]) by sourceware.org (Postfix) with ESMTPS id BE4BD385E017 for ; Fri, 28 Oct 2022 13:06:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE4BD385E017 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=1666962391; 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=Ze3ySPK6ZbzmBVFUFjjkb/2eVK7mXKOIqPK8H/Qo6OL+uuKl+xmAdjqm5DlPy0p17bZTeF IdHpeFV+XQo5oaxdnIQsWJlp6DokRNgKL6xIOL5bVS6VcotUoYPyQT04wgb1EVZ+MCyVyy Sr4hRl7dlq98hrnlvlLc3obGyjmtoYI= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-116-9vHFmhErOuGv6Chbl6Tuxg-1; Fri, 28 Oct 2022 09:06:28 -0400 X-MC-Unique: 9vHFmhErOuGv6Chbl6Tuxg-1 Received: by mail-qt1-f198.google.com with SMTP id 17-20020ac85711000000b0039ccd4c9a37so3324206qtw.20 for ; Fri, 28 Oct 2022 06:06:28 -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=StkV5s5+KtYlOvIVmUuABx28m/+Xy47FMJO3eqv0VmZPZkpKCU1jSAyjh03GR0YZSZ qPSxDd6SaVxlbe0koww3Zm55WlCTepQWEKTo7hgKKV702d0yIDlb5J2/SPpie/rD5X86 sfvp1e8ynlaFmwZJvlTXmo385gJDG3tYCZsugsLR9tAKcp3QTtlklevz8pcTjHHZrE72 Il9mi61yu502Sfi/trhGo2s7lDDYxrHmVXLDuMAYd+8Clrqgl3sMovC5/O/Nj5XgfQFv H3E6f73gD7SxSXfwElSe5zNpZr/QjveJUaHxg1ZdIcrknEVPlozPv5VYsZRo90uKv257 XZyQ== X-Gm-Message-State: ACrzQf1mrORXNzzsA+c0VKjcuO9JAvL40biXODXHGMUjjyUDia6EA8oC +M2igF97u8c00PzEO+G7WHTrdXM4flnQ2VvKdypK6YLvPicCwS5gZXuoe7nJ1zR4ykWnQoFxl8E VlK305HwdkjBpqJT3Ww== X-Received: by 2002:ac8:7f8c:0:b0:39c:db49:29cc with SMTP id z12-20020ac87f8c000000b0039cdb4929ccmr45634040qtj.224.1666962387426; 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=unavailable 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