On 12 December 2011 17:44, Timon Gehr <timon.g...@gmx.ch> wrote: > On 12/12/2011 04:17 PM, Robert Jacques wrote: > >> On Mon, 12 Dec 2011 01:06:14 -0500, Brad Anderson <e...@gnuk.net> wrote: >> >> On Sun, Dec 11, 2011 at 10:55 PM, Robert Jacques <sandf...@jhu.edu> >>> wrote: >>> >>>> Second, being a systems language means that D can not implement a lot of >>>> >>> GC algorithms including copying, generational and the good concurrent >>> collectors. >>> >>> What about being a systems language prevents generational? The page on >>> garbage collection on the D website says while it doesn't use a >>> generational GC it will some day and gives tips on what to avoid so you >>> don't fall victim to the behavior of a moving GC. >>> >> >> Regarding moving collectors. >> D supports semi-precise collection. Therefore D can support some types >> of moving collectors, i.e. compactors, which is what the website is >> talking about. Copying collectors, on the other hand, require full >> precision to work; you must be able to fully evacuate a region of >> memory. D doesn't support full precision, for a couple of performance >> (unions, >> > > The compiler could insert small code fragments that track whether or not > an union contains a pointer. > > the call stack, >> > > What is the problem with the call stack? Can't the compiler just generate > reference offset information for all the function frames and then the GC > generates a backtrace to identify the references? > > C/C++ interop) >> > > There should be multiple options for GC. If C/C++ interop is unimportant, > a better GC that does not support it well is still handy. > > > and technical reasons (the inline >> assembler). >> > > inline assembler does not always move around GC heap references. I think > that in the cases it does, reference stores could be annotated manually. > > >> Regarding generational collectors. >> Both generational and concurrent collectors require that every pointer >> assignment is known to the compiler, which then instruments the >> assignment to flag mark bits, etc. For generational collectors, you need >> this information to know which objects/memory pages to search for roots >> into the young generation. Without this information, you have to search >> the entire heap, i.e. do a full collection. Again, both performance and >> technical reasons come into play here. Instrumentation represents a >> performance cost, which even if it pays for itself, looks bad in >> newsgroups posting. Indeed, concurrent collectors are mostly about >> trading throughput for latency. So, like JAVA, you'd want to use version >> statements to select your GC style, but you'd also have to make sure >> your entire codebase was compiled with the same flags; with 3rd party >> DLLs and objects, this can become non-trivial. From a technical >> perspective, complete pointer assignment instrumentation is a >> non-starter because the D compiler doesn't have complete access to all >> >> the code; both C/C++ and assembler code can modify pointers and are not >> subject to instrumentation. Now, if we supported C/C++ through >> marshaling, like JAVA and C# do, and made the assembler a bit more smart >> or required manual pointer instrumentation of asm code, we could use >> these types of collectors. >> >> * Note that the above doesn't take into account the types of virtual >> memory tricks C4 can do, which may open these algorithms up to D and >> other system programming languages. >> > > I think we'll definitely need a generational/concurrent collector > eventually. Could some of the problems be worked around by having more than > one GC implementation in the same executable? >
Totally off topic... I have a question. If I pass a pointer to a C library... how does the GC know when it's safe to collect?
