"@nogc": the key for efficient low-latency GC?

Golden Rockefeller whitegoldrock at gmail.com
Thu Oct 31 07:25:26 UTC 2019

Having to add write barriers everywhere is a major concern with 
incremental tracing garbage collectors (GCs). But like with 
reference counting (RC), these barriers can be deferred. 
Actually, in contrast with RC, these barriers can be omitted!, 
when storing references to local. "@nogc" is a great tool for 
telling the compiler when it is safe to defer/omit write 
barriers. Here is why I think this:

The hypothetical incremental GC will only trace when memory is 
allocated. For efficiency reasons, the GC shouldn't trace with 
every allocation, but programmers can be sure that the GC will 
never trace if the programmers never allocate.
The point of the write barriers is to preserve the invariant 
condition between traces. So the GC only needs to keep track of 
changes in memory that persists through to the next 
allocation/trace. If code is written in an @nogc area, then the 
compiler only needs to add a write barrier once per variable. For 
example, if I am looping through a list of objects, and storing 
the current object within the loop in "someclass.somemember", 
then the compiler would write a single write barrier for 
someclass.somemember outside of the for loop, and perhaps at the 
end of the function. If I instead store the object in a local 
variable, then I could completely omit the write barriers for 
this variable since this variable will not be around by the next 
allocation. This also works for "inferred @nogc" code. Even if 
the function is not @nogc, the compiler may still be able to 
determine what area within the code will never trigger an 
allocation (and some of the code in this area maybe calling @nogc 

What do you think? I think this makes D unique among other 
languages in its potential to optimize low-latency GC 
implementations but also give programmers control and assurances 
regarding this optimization. At the least, this should all be 
faster and easier to use than C++'s "shared_ptr".

More information about the Digitalmars-d mailing list