• Sean Kelly <sean invisibleduck.org> Sep 03 2010
• Jacob Carlborg <doob me.com> Sep 03 2010
• Sean Kelly <sean invisibleduck.org> Sep 03 2010
• Walter Bright <newshound2 digitalmars.com> Sep 03 2010
• Jacob Carlborg <doob me.com> Sep 04 2010
• Walter Bright <newshound2 digitalmars.com> Sep 04 2010
• bearophile <bearophileHUGS lycos.com> Sep 04 2010
• Walter Bright <newshound2 digitalmars.com> Sep 04 2010
• Jacob Carlborg <doob me.com> Sep 04 2010

Sean Kelly <sean invisibleduck.org> writes:

Justin Johansson Wrote:

 On 02/09/10 08:03, bearophile wrote:
 Is it possible to try to replace (or just perform experiments) the D GC with
this one?

 http://developers.sones.de/2010/09/01/taking-the-new-and-shiny-mono-simple-generational-garbage-collector-mono-sgen-for-a-walk/

 Delegating the creation and management of the D GC to someone else (the Mono
team) sounds like a possible way to have a good enough GC.

 Bye,
 bearophile


 Can you elucidate perhaps a little bit about the theory of the Mono GC
 and why it might be interesting.  Some hypotheses about what makes one
 GC better than another would be nice topics for discussion.


It sounds pretty nice, but this bullet point could be a problem:

* Uses write barriers to min i mize the work done on minor collections.

Jacob Carlborg <doob me.com> writes:

On 2010-09-03 19:58, Sean Kelly wrote:
 Justin Johansson Wrote:

 On 02/09/10 08:03, bearophile wrote:
 Is it possible to try to replace (or just perform experiments) the D GC with
this one?

 http://developers.sones.de/2010/09/01/taking-the-new-and-shiny-mono-simple-generational-garbage-collector-mono-sgen-for-a-walk/

 Delegating the creation and management of the D GC to someone else (the Mono
team) sounds like a possible way to have a good enough GC.

 Bye,
 bearophile


 Can you elucidate perhaps a little bit about the theory of the Mono GC
 and why it might be interesting.  Some hypotheses about what makes one
 GC better than another would be nice topics for discussion.


 It sounds pretty nice, but this bullet point could be a problem:

 * Uses write barriers to min i mize the work done on minor collections.


Why would write barriers be a problem, could you elaborate?

-- 
/Jacob Carlborg

Sean Kelly <sean invisibleduck.org> writes:

Jacob Carlborg Wrote:

 On 2010-09-03 19:58, Sean Kelly wrote:
 It sounds pretty nice, but this bullet point could be a problem:

 * Uses write barriers to min i mize the work done on minor collections.


 Why would write barriers be a problem, could you elaborate?


I think write barriers in this context are calls out to the GC to notify it of
reference changes, and these are generated by the compiler.  A language like D
that can call inline ASM, external C routines, etc, simply can't provide that
guarantee.  SafeD maybe.

Walter Bright <newshound2 digitalmars.com> writes:

Sean Kelly wrote:
 I think write barriers in this context are calls out to the GC to notify it
 of reference changes, and these are generated by the compiler.  A language
 like D that can call inline ASM, external C routines, etc, simply can't
 provide that guarantee.  SafeD maybe.


Such write barriers are a performance problem, too.

Jacob Carlborg <doob me.com> writes:

On 2010-09-04 07:01, Walter Bright wrote:
 Sean Kelly wrote:
 I think write barriers in this context are calls out to the GC to
 notify it
 of reference changes, and these are generated by the compiler. A language
 like D that can call inline ASM, external C routines, etc, simply can't
 provide that guarantee. SafeD maybe.


 Such write barriers are a performance problem, too.


What I've read about garbage collection techniques I got the impression 
that you could implement a better and more efficient collector with 
write barriers that would outweigh the performance loss that comes with 
the barriers.

-- 
/Jacob Carlborg

Walter Bright <newshound2 digitalmars.com> writes:

Jacob Carlborg wrote:
 Such write barriers are a performance problem, too.


 What I've read about garbage collection techniques I got the impression 
 that you could implement a better and more efficient collector with 
 write barriers that would outweigh the performance loss that comes with 
 the barriers.



That's true if the language (like Java) uses a *lot* of gc allocation. D 
programs tend to do much less because it has support for value types.

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright:
 That's true if the language (like Java) uses a *lot* of gc allocation. D 
 programs tend to do much less because it has support for value types.


This is true, unless:
- Someone that knows well enough Java (and badly D) writes a D program. Today
it's hard to find people that know D;
- Someone ports a Java program to D;
- Someone writes some D code where OOP (or automatic heap activity management)
is more necessary (commercial software?).

Bye,
bearophile

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 Walter Bright:
 That's true if the language (like Java) uses a *lot* of gc allocation. D 
 programs tend to do much less because it has support for value types.


 This is true, unless: - Someone that knows well enough Java (and badly D)
 writes a D program. Today it's hard to find people that know D; - Someone
 ports a Java program to D;


The language should focus on supporting D programs best, not Java programs.
Putting write barriers on every write through a pointer will destroy 
performance. In Java, every write through a reference refers to the heap. This 
is not remotely true of D programs.

And, as was mentioned previous, you can't do write barriers halfway. You've got 
to do it everywhere, meaning that simple interfacing to C code is destroyed.


 - Someone writes some D code where OOP (or
 automatic heap activity management) is more necessary (commercial software?).


I don't think it makes sense to characterize commercial software as eschewing 
value types.

Jacob Carlborg <doob me.com> writes:

On 2010-09-04 21:22, Walter Bright wrote:
 Jacob Carlborg wrote:
 Such write barriers are a performance problem, too.


 What I've read about garbage collection techniques I got the
 impression that you could implement a better and more efficient
 collector with write barriers that would outweigh the performance loss
 that comes with the barriers.



 That's true if the language (like Java) uses a *lot* of gc allocation. D
 programs tend to do much less because it has support for value types.


Ok, thanks for the answer.

-- 
/Jacob Carlborg