"@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
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".
More information about the Digitalmars-d
mailing list