• bearophile (5/5) Sep 01 2010 Is it possible to try to replace (or just perform experiments) the D GC ...
• Craig Black (2/2) Sep 03 2010 This would be awesome if the Mono guys were willing to cooperate.
• Justin Johansson (6/11) Sep 03 2010 Can you elucidate perhaps a little bit about the theory of the Mono GC
• Sean Kelly (3/16) Sep 03 2010 It sounds pretty nice, but this bullet point could be a problem:
• Jacob Carlborg (4/20) Sep 03 2010 Why would write barriers be a problem, could you elaborate?
• Sean Kelly (2/9) Sep 03 2010 I think write barriers in this context are calls out to the GC to notify...
• Walter Bright (2/6) Sep 03 2010 Such write barriers are a performance problem, too.
• Jacob Carlborg (7/14) Sep 04 2010 What I've read about garbage collection techniques I got the impression
• Walter Bright (3/9) Sep 04 2010 That's true if the language (like Java) uses a *lot* of gc allocation. D...
• bearophile (7/9) Sep 04 2010 This is true, unless:
• Walter Bright (9/18) Sep 04 2010 The language should focus on supporting D programs best, not Java progra...
• Jacob Carlborg (4/13) Sep 04 2010 Ok, thanks for the answer.
• Steven Schveighoffer (10/15) Sep 03 2010 license-wise, I think it would be possible to just port. The GC portion...

bearophile <bearophileHUGS lycos.com> writes:

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

"Craig Black" <cblack ara.com> writes:

This would be awesome if the Mono guys were willing to cooperate.

-Craig

Justin Johansson <no spam.com> writes:

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.

Cheers
Justin

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Wed, 01 Sep 2010 18:33:40 -0400, bearophile <bearophileHUGS lycos.com>  
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.

license-wise, I think it would be possible to just port.  The GC portion  
of mono is licensed via MIT X/11

It says it's semi-precise (everything except registers and stack, which  
are scanned conservatively).  ATM, D doesn't have enough data to have  
precise scanning (though there is work being done on that).

I don't see why it wouldn't be possible to try out this GC, it seems to be  
mostly usable in a D environment.

-Steve