A benchmark, mostly GC

[Timon Gehr]

On 12/12/2011 04:17 PM, Robert Jacques wrote:
> On Mon, 12 Dec 2011 01:06:14 -0500, Brad Anderson <eco at gnuk.net> wrote:
>
>> On Sun, Dec 11, 2011 at 10:55 PM, Robert Jacques <sandford at 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?