On Thu, Jan 20, 2022 at 11:56:42PM +0000, Chris Katko via Digitalmars-d wrote:
> I just found out that Unity has incremental garbage collection. I didn't know that was a possibility for GCs.
[...]

AFAIK, Ruby has had it ages ago. It's not a new idea.


> Is that an option on a hypothetical level, for D? Or does D's language design preclude that. I recall some sort of issue with using Java/C#/whatever's garbage collector because it would have to insert memory barriers into D to work or something like that.

Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchonization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.


> Also, it's hard to find one specific place for "news" regarding D's garbage collector development and "omg we deleted everything GC from the standard library" projects. Are there any major updates on those fronts?

https://dlang.org/blog/the-gc-series/

The GC isn't going anywhere.  AFAIK there's some work to eliminate *unnecessary* GC usage in Phobos, et al, but there is no such project to remove *all* GC use from Phobos.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:
> I'm just curious what the D language community's thoughts are on it. The tradeoff is: For
> a longer total time / lower throughput, you reduce stress on individual frames which prevents hiccups. That's pretty darn important for games and soft/hard real-time systems.

You can already avoid pauses by simply not allocating.  I would prefer to see a generational gc (much higher throughput).  Note also incremental is not a panacea; the mutator can still get ahead of the collector; go has a somewhat laughable solution to this.

On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:
> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchonization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.

I have heard this claim before.  I don't buy it.

1. Barriers are not that slow.  It is not a 'synchronization'; it is a cheap compare-and-branch that will be correctly predicted.  (Nobody complains about bounds checking...)

2. You do not need a barrier on _every_ pointer write

3. It can be a compile-time option to disable it

4. Lack of typed pointers (gc/non-gc) can be solved conservatively with monomorphization

On 1/20/2022 5:46 PM, Elronnd via Digitalmars-d wrote:
> On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:

>> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchronization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.
> 
> I have heard this claim before.  I don't buy it.

This is clearly an area where anecdotals like "Walter will never accept this" aren't useful.  There's ample evidence to show that he accepts when he's proven wrong.

To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.

Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

On 21/01/2022 3:17 PM, Brad Roberts wrote:
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
> 
> Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

I've recently bought (but waiting on delivery) The Garbage Collection Handbook. It covers generational GC's, memory allocators (which is what I'm interested in) and like 13 pages on write barriers.

It would be an interesting experiment to see if we added a -enablewb flag and have it enable more GC options at runtime, if this allowed some better fitting GC's.

On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
>
> Someone with a good background in GC's needs to step up and be its champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

I agree.  But: it is an involved task that will likely not bear fruit until it is nearly done; I do not expect an implementation would perform very well until it performed the optimizations I mentioned elsewhere.  (Well, a first step would be to make the precise gc actually precise, which would benefit everybody; but after that...)

For my part, I think it would be a fun project, but it would not be a high enough priority for me to see it through unless somebody were paying me to do it full time (and who would pay for an 'unproven' idea? It is exactly the problem you identify).  Maybe rikki will be the champion :)

On 21/01/2022 5:48 PM, Elronnd wrote:
> Maybe rikki will be the champion :)

I've considered it, but it wouldn't align with what I am doing with D atm.

I'd also like to see is fiber aware GC hooks and configurable memory allocator.

On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
> On 1/20/2022 5:46 PM, Elronnd via Digitalmars-d wrote:
>> On Friday, 21 January 2022 at 00:55:43 UTC, H. S. Teoh wrote:
>
>>> Write barriers are required for an incremental GC to work. Write barriers are unlikely to be accepted in D because they introduce synchronization overhead per pointer write. This would kill D's performance in low-level code, and I don't think Walter will ever accept this.
>> 
>> I have heard this claim before.  I don't buy it.
>
> This is clearly an area where anecdotals like "Walter will never accept this" aren't useful.  There's ample evidence to show that he accepts when he's proven wrong.
>
> To make any progress towards a better GC it's going to have to be demonstrated.  And the proof will justify the changes.  If they're good and the complexities required to get there aren't awful, then they'll make into the code base.  If they're not, then they wont.  The status quo is easy to get stuck in and help no one.
>
> Someone with a good background in GC's needs to step up and be it's champion.  I expect that several people would rally to help once some basic momentum is established.  So, willing to be the rallying cry and step up?

To be honest, that is something that is more fun to do in the Go, .NET and Java communities, because not only no one cares about the matra that on a systems programming language GC verbotten is supposed to be a thing, there are hardware companies shipping real products with them.

So in those communities the whole discussion isn't if GC belongs or not in a systems programming language, being rebooted every couple of months, rather how to improve it to the point that e.g. writing firmware in Go is a reality that one can ship into a commercial product (USB Armory).