On Fri, Oct 28, 2022 at 1:45 PM Arthur Cohen <arthur.co...@embecosm.com> wrote: > > Hi David, > > On 10/26/22 23:15, David Malcolm wrote: > > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@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<T, tree> 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 > > > >
