On 21/01/2022 10:34 PM, Ola Fosheim Grøstad wrote:
>> 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.
> 
> I think many programmers would shoot themselves in the the foot in @nogc code... You would need very good documentation and tutorials for that to be a reasonable option.

Yeah in practice this may require UDA's and all sorts to guarantee good speeds. With very easy to ways to segfault.

Not necessarily something D as a whole wants to go in, hence opt-in rather than opt-out.

On Friday, 21 January 2022 at 02:17:34 UTC, Brad Roberts wrote:
>
> 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?

I've been nagging about this for ages it feels. The problem is that D as no managed pointers. If that was the case, it would enable a myriad of GC possibilities for the D community to experiment with different GC algorithms. This at the same time keeping the possibility that managed pointers is just a pointer like today.

Today it doesn't matter if we have world class GC experts in the D community as the language itself limits what you can implement.

D suffers from that what can be seen in several other inventions. The inventor thinks that the invention is perfect and do not want to develop it further even if the shortcomings are obvious. Some other inventor comes along and drastically improves the design and the product really shoots off in popularity.

On Friday, 21 January 2022 at 10:00:17 UTC, IGotD- wrote:
> The problem is that D as no managed pointers.

Again, this can be solved conservatively at the implementation-level.

On Friday, 21 January 2022 at 10:13:17 UTC, Elronnd wrote:
>
> Again, this can be solved conservatively at the implementation-level.

Basically no.

D has a lot of standard library types in druntime/phobos, like arrays and other containers. Even if you implement your own GC at implementation level, the standard library types will still use the default GC and having other GC properties you probably don't want. Managed pointers enables you to swap out the entire default GC all together including GC usage in the standard library.

On 21/01/2022 11:58 PM, Ola Fosheim Grøstad wrote:
> It would work for D, I guess.

Not likely, it would need a lot of work to bring that up to todays requirements.

For context:

A heap size of less than 1 megabyte may work very well. The cost
of duplicating a heap of 100.000 bytes only takes up about 2% extra cpu time on my
single processor personal computer from 2002-2003 running a blocksize of 128.
(Note that a more common blocksize of 1028 would yield a cpu usage of 1/8 of 2%).
Furthermore, since todays computers are many times faster than
this, especially those with 4 or 8 cores, (which the garbage collector
is able to fully utilitize (well, at least that's the plan)), the number
of bytes in the heap can probably be multiplied many times.

As long as the heap is reasonable small, which it probably should be while doing signal processing
tasks, duplicating the entire heap should not be a costly operation with current personal
computers. On a multiprocessor machine, using heaps of many megabytes should not
be a problem. I've also successfully tried using a 20MB heap on a dual-core intel machine.

On Friday, 21 January 2022 at 10:42:58 UTC, IGotD- wrote:
>> Again, this can be solved conservatively at the implementation-level.
> Basically no.
> Managed pointers enables you to swap out the entire default
> GC all together including GC usage in the standard library.

I guess I was insufficiently clear.  My bad.  I am talking about a mechanism that works without needing to modify any existing code.  Let's say we have this:

void f(int** x) {
	*x = new int;
}
void g() {
	int** x = new int*;
	f(x);
	int* y;
	f(&y);
}

and we want to add a generational gc, which barriers.  So naively we rewrite f as follows:

void f(int** x) {
	store_barrier(x, new int);
}

This will involve overhead because we don't know if x is a gc pointer or not.  So instead, generate multiple definitions and rewrite callers:

void f_gc(int** x) {
	store_barrier(x, new int);
}
void f_nogc(int** x) {
	*x = new int; //no barrier!
}
void g() {
	int** x = new int*;
	f_gc(x);
	int* y;
	f_nogc(&y); //no overhead from passing stack object!
}

Of course this transformation is conservative: you will sometimes call f_gc with a non-gc pointer.  But I bet it works 99% of the time such that the runtime overhead is negligible in practice.

On 22/01/2022 12:27 AM, Ola Fosheim Grøstad wrote:
> On Friday, 21 January 2022 at 11:06:58 UTC, rikki cattermole wrote:
>>
>> On 21/01/2022 11:58 PM, Ola Fosheim Grøstad wrote:
>>> It would work for D, I guess.
>>
>> Not likely, it would need a lot of work to bring that up to todays requirements.
> 
> What are the requirements?

That project was a masters thesis in 2009 running on 2002 era hardware.

Size of data has changed, hardware has changed. It'll need work to prove it can even do the sort of workloads D has even in audio space.