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?
