> You don't really need to wait for me, write a better gc! The one that's in there now aimed to simply work correctly and get D off the ground.

Hm, the problem is that most of the more interesting GC algorithms require changes to the compiler/runtime environment. Conservative GC is actually a bad idea with a language/environment that's designed for use with garbage collection, simply because one can do without any scanning for pointers, *given that the compiler provides the necessary metadata about data structures in the program* :)

Some algorithms (like the Realtime GC one for which I posted a link to the paper yesterday) also require read or write barriers, which also need to be implemented in code generation.

Overall I doubt that a truly efficient GC can be done as just a pluggable library module - it requires very close cooperation with the compiler.

-fg

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns93A4C9961DCBFitsFarmer@63.105.9.61...
> In fact, current DMD always allocates auto classes on the gc-heap. The destructor is called when the reference goes out of scope, but the memory
of
> auto classes is not freed immediately, instead it is released during
normal
> garbage collection.

Correct, but it is within the semantics of the language to put them on the stack.

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EF88CB3.80A35237@hls.via.at...
> Walter wrote:
> > "Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bd9rqm$1mde$1@digitaldaemon.com...
> > > > I don't think that current GC in D is good enough.
> > > I agree with that, and I also think the bad image of GC is partly due to the fact of most garbage collectors actually used in practice are far from state of the art. But then, Walter has already mentioned several times that his focus is currently on the compiler and not the runtime support.
> > You don't really need to wait for me, write a better gc! The one that's
in
> > there now aimed to simply work correctly and get D off the ground.
> Is it possible to replace or extend the current GC module?

Yes.

> If yes, what are the interfaces to the current system?

It's designed to be replaced. Check out gc.d, all it does is forward the calls to another, hidden class. Those calls would be the interface.

"Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bdabu4$62p$1@digitaldaemon.com...
> Hm, the problem is that most of the more interesting GC algorithms require changes to the compiler/runtime environment. Conservative GC is actually a bad idea with a language/environment that's designed for use with garbage collection, simply because one can do without any scanning for pointers, *given that the compiler provides the necessary metadata about data structures in the program* :)
>
> Some algorithms (like the Realtime GC one for which I posted a link to the paper yesterday) also require read or write barriers, which also need to be implemented in code generation.
>
> Overall I doubt that a truly efficient GC can be done as just a pluggable library module - it requires very close cooperation with the compiler.

Write barriers can be done entirely within the gc, if the paging hardware is used to implement them.

> Write barriers can be done entirely within the gc, if the paging hardware is used to implement them.

I doubt that using paging to detect pointer writes is a good idea. You'd get literally tons of page faults using that technique to detect pointer writes for data structures that often change. And a page fault is far from cheap :)

-fg

"Fabian Giesen" <rygNO@SPAMgmx.net> wrote in message news:bdajmr$d0s$1@digitaldaemon.com...
> > Write barriers can be done entirely within the gc, if the paging hardware is used to implement them.
> I doubt that using paging to detect pointer writes is a good idea. You'd get literally tons of page faults using that technique to detect pointer writes for data structures that often change. And a page fault is far from cheap :)

For a generational collector, how it works is for the 'old' generation, the pages are marked read-only. If anyone writes to a page, that generates a fault. The gc catches the fault, marks the page as "needs to be rescanned", turns on write for that page, and restarts the offending write instruction.

The reason it is effective is because statistically old generation pages are rarely written to, and the overhead of a page fault only happens once per page, not for every write.

The scheme would work even better if the paging hardware was set up to work with the gc and collect the dirty bits automatically. Unfortunately, no operating system I know of provides an API for that.

Walter wrote:
> > Is it possible to replace or extend the current GC module?
> 
> Yes.
> 
> > If yes, what are the interfaces to the current system?
> 
> It's designed to be replaced. Check out gc.d, all it does is forward the calls to another, hidden class. Those calls would be the interface.

I think that the GC is one of the vital part of D and it would be a really good thing to have a workgroup dealing with all related issues.

Possible goals for the start (please extend list):
  - analyze, understand and document the current collector
  - make the collector plugable (document the necessary steps to replace it)
  - build a GC testsuite for benchmarking and language comparisons
  - building, testing and suggesting alternative collectors
  - ...

Who is interested to collaborate?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

In article <3EF947F1.5BAD3D2D@hls.via.at>, Helmut Leitner says...
>
>I think that the GC is one of the vital part of D and it would be a really good thing to have a workgroup dealing with all related issues.
>
>Possible goals for the start (please extend list):
>  - analyze, understand and document the current collector
>  - make the collector plugable (document the necessary steps to replace it)
>  - build a GC testsuite for benchmarking and language comparisons
>  - building, testing and suggesting alternative collectors
>  - ...
>Who is interested to collaborate?

While it's unlikely that I'll submit code, I could contribute the same way as I've done in this newsgroup. If this is welcome, then I'm in.

> For a generational collector, how it works is for the 'old' generation, the pages are marked read-only. If anyone writes to a page, that generates a fault. The gc catches the fault, marks the page as "needs to be rescanned", turns on write for that page, and restarts the offending write instruction.
>
> The reason it is effective is because statistically old generation pages are rarely written to, and the overhead of a page fault only happens once per page, not for every write.

Hm okay, now that I think of it, that *would* make sense. Definitely worth a try :)

-fg

Georg Wrede wrote:
> 
> In article <3EF947F1.5BAD3D2D@hls.via.at>, Helmut Leitner says...
> >
> >I think that the GC is one of the vital part of D and it would be a really good thing to have a workgroup dealing with all related issues.
> >
> >Possible goals for the start (please extend list):
> >  - analyze, understand and document the current collector
> >  - make the collector plugable (document the necessary steps to replace it)
> >  - build a GC testsuite for benchmarking and language comparisons
> >  - building, testing and suggesting alternative collectors
> >  - ...
> >Who is interested to collaborate?
> 
> While it's unlikely that I'll submit code, I could contribute the same way as I've done in this newsgroup. If this is welcome, then I'm in.

That certainly *is* welcome. Thinking is more important than coding.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com