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