A benchmark, mostly GC

[Manu]

On 12 December 2011 17:44, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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?
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111212/4c6462fd/attachment.html>