@Araq, regarding saving time in atomic ref counts and shared allocations: > 1. I think you will be surprised when you benchmark this. ;-) > 2. There is also a different solution: > 3. Keep in mind that this is only a dangling ref detector... >
I see what you mean now: ref counting only happens when the ref counting checking is turned on with a future pragma/compiler switch and in fact, when it's turned off there doesn't even need to be a ref count field. As you said, then all ref counting is of zero cost, of minimal cost except when "threads" is on and "threadSafe" is defined, can be of minimal cost if it recognizes use in a threadvar and therefore we would only have a cost if ref counting checking is left on **and** "threads:on" is set **and** "threadSafe" is defined **and** it is not a "threadvar" \- not so bad. With ref count checking turned off, this truly is a minimal cost memory management system! As to the Allocator refinements, I'm sure those will come and some don't need locks as in using compare-and-atomic-swap the check if memory was successfully allocated or not to avoid even thread barriers/critical section waits along with the other allocation tricks you mentioned; the good thing is that we can play with Allocators all we want after version 1.0 without breaking changes. At any rate, according to my quick benchmarks, even using full sharing allocations with barriers is about 20% faster than using the current default non-sharing GC, and as we agree, we could tweak the allocator in many ways. I'm getting excited about implementing this! I'm excited enough to implement a trial test on top of Nim version 0.20.0 without doing any compiler magic to see if there are any specification problems, am encountering some problems, but have been able to work around them. More on that a little later when I get a little further...
