2 ms·

Ah, interesting to know that Nim's system uses some form of affine/linear types. I'm not sure of the extent or details as I've been busy making use of other par

Ah, interesting to know that Nim's system uses some form of affine/linear types. I'm not sure of the extent or details as I've been busy making use of other parts of Nim, but I really want to read up on linear types. Nim's type system is powerful enough to pass write effects which would be pretty handy for first class immutability [1]. Not sure how much that overlaps with linear types though or if it's an orthogonal aspect. On a side note, my use case of a Bacon-Arjan type collector ... Interesting story! I enjoy reading those, and I know the Nim team had a lot of work to get ARC & ORC working well, which also required a lot of work on move/sink as well in the stdlib. I could see it being very difficult to implement in a big C++ code base. From the article it seems M&S can even be a bit faster than ARC, but with higher latency, more memory usage, and harder to target various platforms like WASM. I'm glad as it makes Nim excellent for usage on microcontrollers! No worries on shared heaps or unpredictable GC pauses. 1: https://nim-lang.org/araq/writetracking_2.html https://nim-lang.org/araq/writetracking_2.html

KMag 6y ago
The total CPU overhead of M&S should be proportional to the number of live objects times the rate of object allocation. (Traditionally, collections were triggered every so many allocations or so many bytes allocated, but heuristics based on the amount of free heap would give similar behavior.) The total CPU overhead of reference counting is proportional to the rate of reference creation and destruction. You can really bring this down if your compiler is told or can figure out which references can be borrowed. The best case for reference counting is where the compiler is told (or can infer) which references are borrowed, and the code is written in a style that mostly borrows references, and rarely mutates data structures. One interesting hybrid approach is "one bit reference counting". You have a 1-bit flag in the object header that gets set when a reference to the object gets copied. If a reference gets destroyed, and the object doesn't have the flag set, that means that the referenced object is garbage. Lots of objects never have more than one reference to them, and this little tweak allows for more immediate reclamation of many objects, which allows you to get away with doing tracing GC less often.

KMag 6y ago

The total CPU overhead of M&S should be proportional to the number of live objects times the rate of object allocation. (Traditionally, collections were triggered every so many allocations or so many bytes allocated, but heuristics based on the amount of free heap would give similar behavior.) The total CPU overhead of reference counting is proportional to the rate of reference creation and destruction. You can really bring this down if your compiler is told or can figure out which references can be borrowed. The best case for reference counting is where the compiler is told (or can infer) which references are borrowed, and the code is written in a style that mostly borrows references, and rarely mutates data structures. One interesting hybrid approach is "one bit reference counting". You have a 1-bit flag in the object header that gets set when a reference to the object gets copied. If a reference gets destroyed, and the object doesn't have the flag set, that means that the referenced object is garbage. Lots of objects never have more than one reference to them, and this little tweak allows for more immediate reclamation of many objects, which allows you to get away with doing tracing GC less often.