> Does adding fake machine insns to the automatic root inference scheme yield support for moving collectors?
Not sure about your other questions, but this document answers your questions in regards to moving GCs: https://github.com/elliottslaughter/rust-gc-notes "The disadvantage was that this would limit what GC algorithms we could make use of. Specifically, LLVM would be free to make copies of pointers and put them anywhere, so we wouldn't necessarily know about all copies of given pointer. So we wouldn't be able to implement any moving GC algorithms with this approach, leaving primarily mark-and-sweep GC algorithms on the table." On Wed, Sep 12, 2012 at 4:21 PM, Ben Karel <[email protected]> wrote: > On Fri, Sep 7, 2012 at 7:17 PM, Elliott Slaughter > <[email protected]>wrote: > >> Hi all, >> >> As of cb53623341, precise GC-based cleanup has landed in incoming. There >> are still many rough edges, but this should be enough to get your feet wet >> and try the GC out. >> >> I have written up a document describing the GC implementation details, >> current status, etc. You can find it here: >> >> https://github.com/elliottslaughter/rust-gc-notes >> >> Thanks everyone for a great summer. I have to say, Rust is by far my >> favorite language now. I had a lot of fun working on GC, and I hope this is >> the beginning of real GC support in LLVM. >> >> -- >> Elliott Slaughter > > > This looks interesting! I had a few questions after reading your notes: > > Does adding fake machine insns to the automatic root inference scheme > yield support for moving collectors? I'm not clear on how root inference > avoids the problems with GC-invariant-violation associated with explicit > register roots. > > It sounds like root inference is structured as a transformation from IR to > IR-plus-fake-gcregroot-insns, rather than from IR to > IR-plus-stack-roots-and-gcroot-annotations. Is this accurate? Is the > motivation mainly to reuse the existing liveness computation for machine > instructions, rather than re-implementing liveness for LLVM IR? Or are > there other motivations to avoid optimized insertion of gcroot > slots/loads/etc? > > Regarding cleanup, you note that stack allocations lack the object header > associated with heap allocations. Is there an obstacle to adding such a > header to stack allocations? > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
