www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The new Mono GC

reply 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
Sep 01 2010
next sibling parent "Craig Black" <cblack ara.com> writes:
This would be awesome if the Mono guys were willing to cooperate.

-Craig
Sep 03 2010
prev sibling next sibling parent 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
Sep 03 2010
prev sibling next sibling parent reply 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.
Sep 03 2010
parent reply 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
Sep 03 2010
parent reply 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.
Sep 03 2010
parent reply 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.
Sep 03 2010
parent reply 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
Sep 04 2010
parent reply 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.
Sep 04 2010
next sibling parent reply 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
Sep 04 2010
parent 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.
Sep 04 2010
prev sibling parent 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
Sep 04 2010
prev sibling parent "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
Sep 03 2010