I do not know much about GC, but it seems that there are basic categories of GC needs (goals).
One need that popped up in my reading is that concerning the difference between Pause times and how it affects Real Time needs: Stop the Word > .5 sec (typically) Incremental near >.4 ms Real-time < .4ms I found this PowerPoint to be interesting, just from a perspective of visualizing the problem space itself: http://www.research.ibm.com/metronome/talks/Bacon03RealtimeTalk.ppt and this one: http://www.cs.cmu.edu/~blelloch/papers/SBH05.pdf And in reading what others have found and what I found, it made me curious with some general questions to all (I have no idea what I'm talking about, but learning here): 1. Is it in everyone's experience that the main limiting factor in a GC is within the FFI and the limits of "when" objects can be relocated ? Is that the highest level need ? 2. Would one of the goals of Rust be eventually to have Real Time GC that could be used in say Real-time embedded systems, like in automobile core engine systems (where Java has a place now)? 3. I would love to see a summary of all the buzzwords that Rust's eventual goals of GC would be able to handle, and what the real goals will be...laid out, and the reasons for each of those goals. Do we have this type of summary yet floating around ? (thanks for schooling me in advance...lol) On Thu, Jul 11, 2013 at 7:29 AM, Felix S. Klock II <[email protected]>wrote: > On 11/07/2013 13:30, Felix S. Klock II wrote: > > On 10/07/2013 22:04, Graydon Hoare wrote: > > I assume you've read this: > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-8.pdf > > This is also relevant, I think (and more recent): > > > Antony L. Hosking. 2006. Portable, mostly-concurrent, mostly-copying > garbage collection for multi-processors. In *Proceedings of the 5th > international symposium on Memory management* (ISMM '06). ACM, New York, > NY, USA, 40-51. DOI=10.1145/1133956.1133963 > http://doi.acm.org/10.1145/1133956.1133963 > > http://dl.acm.org/citation.cfm?id=1133963 > > Caveat: The latter paper that I cited is for a Modula-3 compiler/runtime > (i.e., compiler support for the GC is definitely provided; in other words: > "cooperative software environment"). > > The former paper that Graydon cited is for the explicitly uncooperative > environment of C++; no hardware nor compiler support. > > I presume Rust falls somewhere between these two extremes, so both may be > relevant. > > Cheers, > -Felix, (still playing catchup) > > > -- > irc: pnkfelix on irc.mozilla.org > email: {fklock, pnkfelix}@mozilla.com > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > -- -Thad Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
