www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - " nogc": the key for efficient low-latency GC?

reply Golden Rockefeller <whitegoldrock gmail.com> writes:
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 
functions).

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".
Oct 31 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 31, 2019 at 07:25:26AM +0000, Golden Rockefeller via Digitalmars-d
wrote:
 Having to add write barriers everywhere is a major concern with
 incremental tracing garbage collectors (GCs).
[...] D does not have write barriers, and judging from what Walter has said in the past, it never will. T -- Любишь кататься - люби и саночки возить.
Oct 31 2019