digitalmars.D - " nogc": the key for efficient low-latency GC?
- Golden Rockefeller (33/33) Oct 31 2019 Having to add write barriers everywhere is a major concern with
- H. S. Teoh (8/10) Oct 31 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".
Oct 31 2019
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