What's the go with the GC these days?

welkam wwwelkam at gmail.com
Mon Jan 7 15:54:32 UTC 2019


On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
> poor implementation of a sorely outdated GC?
The whole r/programming needs to be garbage collected. I cant 
find a source but if I recall correctly mark and sweep GC has the 
highest program throughput of all GCs.

> What is this business about write barriers making the GC fast?

In Java and other managed languages common code has lots of small 
short lived objects and not a lot of pointer modifications so 
adding write barriers can get you concurrent GC for almost free. 
For a programmer like you that can turn heap allocations to 
stack, use scope(exit) or similar for simple allocations and 
leave difficult allocations to GC you wont benefit from them.


> It's obvious that the quality of the GC implementation is a 
> mental barrier to entry for many...<...> we do need to care 
> about this as a group, and nobody seems to be making 
> substantial progress.

For things to change we need to change minds. I have watched many 
debates in religion, climate change and politics and saw just how 
hard it is to change some people opinions. The best hope is to 
target people in the middle that dont have strong opinions one 
way or another and repeatedly expose to information that shows 
that GC is not a problem.

Its not correct to say that people in this group dont care its 
just that everything needs work and this is not the only problem 
that D have. I have idea for D blog that would some what address 
this problem but I know myself and I know that there is low 
chance for this idea to materialize. I even picked title - "Why D 
with GC is faster than your C/C++ code" TL;DR memory management

> Is progress possible, or is the hard reality that the language 
> is just designed such to be resistant to a quality GC

With dip1000 in principle we can reduce overhead of GC by 
replacing GC allocations to stack or malloc making generational 
GC necessary.


More information about the Digitalmars-d mailing list