On 4/7/10 22:58, Robert Jacques wrote:
On Wed, 07 Apr 2010 17:34:09 -0300, Jacob Carlborg <[email protected]> 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.
