On Thursday, 25 December 2014 at 14:55:32 UTC, Xinok wrote:
> On Thursday, 25 December 2014 at 10:52:07 UTC, Martin Nowak wrote:
>> On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
>>> (1) We need a precise garbage collector. The fact that a garbage-collected language experiences memory leaks truly reflects poorly on on D.
>>
>> What's the reason for leakage? I'm a bit skeptical about the precise GC work.
>> https://github.com/D-Programming-Language/druntime/pull/1057#issuecomment-65918407
>
> Perhaps "leakage" is the wrong term to use here. I'm referring to the fact that a conservative garbage collector fails to distinguish between pointers and non-pointers, so it happens that dead objects fail to get collected. It's a much greater problem on 32-bit with the limited address space, especially if you perform many large allocations.

Ah OK, thought you had problems with stale stack values.
False pointers were discussed here https://youtu.be/LQY1m_eT37c?t=23m0s, but it's an issue that only affects few programs (32-bit with floats or random data in GC scanned memory). So unless we can use precise GC info to speed up marking, it will be a lot of work with little impact, even more since we have Win64 support.

On Thursday, 25 December 2014 at 20:00:43 UTC, Martin Nowak wrote:
> On Thursday, 25 December 2014 at 14:55:32 UTC, Xinok wrote:
> Ah OK, thought you had problems with stale stack values.
> False pointers were discussed here https://youtu.be/LQY1m_eT37c?t=23m0s, but it's an issue that only affects few programs (32-bit with floats or random data in GC scanned memory). So unless we can use precise GC info to speed up marking, it will be a lot of work with little impact, even more since we have Win64 support.

Any program that processes significant amounts of information, such as scientific data, images, or videos, is likely to experience issues with the conservative GC. While it would be nice to say "just use 64-bit" to everybody, we can't ignore the fact that 32-bit is still widely used and it's not going away anytime soon. As for Win64 support, I've found it iffy at best; sometimes it works, sometimes it doesn't.

I think implementing a precise GC would be worth it in the long run. The key is realizing that there are many optimizations that can be applied which are impossible with a conservative GC. It may make programs a bit slower initially, but it's something that we can optimize over time (well beyond the 2015 goal).

Other languages that have transitioned from conservative to precise have experienced gains and losses in different suites of applications. In particular, programs that perform a lot of allocations actually saw better performance from the precise GC. Some languages benefit more from a precise GC more than others, so it's hard to say how successful it would be in D.

On Friday, 26 December 2014 at 00:05:49 UTC, Xinok wrote:
> On Thursday, 25 December 2014 at 20:00:43 UTC, Martin Nowak wrote:
>> On Thursday, 25 December 2014 at 14:55:32 UTC, Xinok wrote:
>> Ah OK, thought you had problems with stale stack values.
>> False pointers were discussed here https://youtu.be/LQY1m_eT37c?t=23m0s, but it's an issue that only affects few programs (32-bit with floats or random data in GC scanned memory). So unless we can use precise GC info to speed up marking, it will be a lot of work with little impact, even more since we have Win64 support.
>
> Any program that processes significant amounts of information, such as scientific data, images, or videos, is likely to experience issues with the conservative GC.

Would a well supported RC scheme be better than a precise GC for
these use cases?

On Fri, 26 Dec 2014 00:05:47 +0000
Xinok via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Other languages that have transitioned from conservative to precise have experienced gains and losses in different suites of applications. In particular, programs that perform a lot of allocations actually saw better performance from the precise GC. Some languages benefit more from a precise GC more than others, so it's hard to say how successful it would be in D.
besides, it's always easy to use conservative GC instead of precise GC. the reverse is not true.

On Fri, 26 Dec 2014 00:13:57 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 26 December 2014 at 00:05:49 UTC, Xinok wrote:
> > On Thursday, 25 December 2014 at 20:00:43 UTC, Martin Nowak wrote:
> >> On Thursday, 25 December 2014 at 14:55:32 UTC, Xinok wrote: Ah OK, thought you had problems with stale stack values. False pointers were discussed here https://youtu.be/LQY1m_eT37c?t=23m0s, but it's an issue that only affects few programs (32-bit with floats or random data in GC scanned memory). So unless we can use precise GC info to speed up marking, it will be a lot of work with little impact, even more since we have Win64 support.
> >
> > Any program that processes significant amounts of information, such as scientific data, images, or videos, is likely to experience issues with the conservative GC.
> 
> Would a well supported RC scheme be better than a precise GC for these use cases?
it depends of many things, including data allocation and access patterns. for some of them precise generational GC can be a much better choice, as it can discards the whole pages of "newdead" objects without scanning.

yet we need some read or write barriers for this, preferably with support from the compiler.