digitalmars.D - Re: The new Mono GC
- 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
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
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
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
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
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
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
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
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
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