garbage collection in d

[Jacob Carlborg]

On 4/7/10 22:58, Robert Jacques wrote:
> On Wed, 07 Apr 2010 17:34:09 -0300, Jacob Carlborg <doob at me.com> wrote:
>
>> On 4/7/10 20:40, Sean Kelly wrote:
>>> Daniel Oberhoff Wrote:
>>>>
>>>> b) my reluctance to the dependency on a complex runtime as the one d i
>>>> is bringing at least due to its garbage collector
>>>>
>>>> b) worries me a little. I am working towards real time systems with
>>>> tight time and sometimes also tight memory constraints, and a
>>>> conservative stop-the-world collector seems a bit daunting in this
>>>> context. is it reasonable to work without the collector, or are there
>>>> plans to upgrade to a concurrent one. also are there extensive
>>>> performance tests as how badly the collector interrupts real-time
>>>> processing?
>>>
>>> It's still possible to build druntime with a custom GC. You can even
>>> have a "GC" that simply calls malloc/free if you avoid coding that
>>> relies on implicit collection of discarded memory. See gc_stub for an
>>> example. As for better GC implementations, there are a bunch of
>>> options, but I don't know that we can go so far as an incremental
>>> collector ala Java. That D can call C code causes problems there.
>>
>> Maybe something like the AutoZone collector on Mac OS X:
>> http://www.opensource.apple.com/source/autozone/autozone-77.1/README.html?f=text
>>
>>
>> "AutoZone is a scanning, conservative, generational, multi-threaded
>> garbage collector."
>>
>> "... the implementation is language agnostic".
>>
>> "The AutoZone collector is implemented in C++ and is designed to work
>> in a runtime where some or most of the application's memory may be
>> managed by mechanisms other than the collector."
>
> Via reddit:
>> How does it compare to boehm?
>>> Boehm is a drop in replacement for malloc. Autozone requires changes
>>> to the compiler to emit write barriers, and enforces certain coding
>>> constructs - so it doesn't "just work" and requires some changes to
>>> adopt it. But autozone can be more efficient at collecting as a result.
>>> Also autozone collects and runs finalizers in a background thread -
>>> AFAIK Boehm does not.It's better for interactive desktop apps. Boehm
>>> is better for long-running server processes. The trade off is more
>>> fragmentation with AutoZone for faster speeds for relatively
>>> short-living desktop apps.
>
> So autozone is language agnostic but not compiler agnostic, so calling C
> functions or using assembly is still a problem.

I suggested autozone because I assume we could make the necessary 
modifications to the D compiler to support a similar gc. And since it's 
designed to work in a runtime where most of the other applications don't 
use a gc it would be a good choice for D. But I don't know much about 
these things.