Kindof unrelated to the article, but I was recently wondering if it would be possible to detect and deny pointer cycles in a language in an efficient way, so that you could then use simple reference counting instead of full-blown garbage collection. It probably wouldn't be usable for a general-purpose programming language, but for a special-purpose scripting language I could see it making the language implementation…
Fundamentals of garbage collection (2023)
21–30 of 34 posts
Re: Fundamentals of garbage collection (2023)
#22Earlier quoted context omitted.
Hello, I'm writing an implementation of the Common Lisp language that uses an enhanced reference counting algorithm (that I've taken from literature) that detects and handles cycles. Performance seems okay, though I still haven't tried large programs. https://savannah.nongnu.org/p/alisp
A somewhat different approach was recently proposed here: https://news.ycombinator.com/item?id=44319427 but it seems to have non-trivial overhead. (Still very much worthwhile, given the potential advantages of deterministic cycle collection.) The paper you reference is quite a bit older so it would of course be interesting to do a proper comparison.
Re: Fundamentals of garbage collection (2023)
#23Kindof unrelated to the article, but I was recently wondering if it would be possible to detect and deny pointer cycles in a language in an efficient way, so that you could then use simple reference counting instead of full-blown garbage collection. It probably wouldn't be usable for a general-purpose programming language, but for a special-purpose scripting language I could see it making the language implementation…
On any one object you can just follow the references to see if you get back to the same object. Not super efficient as you’d have to do it for each reference as it is set. But if it was a simple scripting language and you needed that constraint, it’s relativity easy to implement.
Re: Fundamentals of garbage collection (2023)
#24Kindof unrelated to the article, but I was recently wondering if it would be possible to detect and deny pointer cycles in a language in an efficient way, so that you could then use simple reference counting instead of full-blown garbage collection. It probably wouldn't be usable for a general-purpose programming language, but for a special-purpose scripting language I could see it making the language implementation…
Like Rust if it has no Rc?
Re: Fundamentals of garbage collection (2023)
#25Kindof unrelated to the article, but I was recently wondering if it would be possible to detect and deny pointer cycles in a language in an efficient way, so that you could then use simple reference counting instead of full-blown garbage collection. It probably wouldn't be usable for a general-purpose programming language, but for a special-purpose scripting language I could see it making the language implementation…
You can make a programming language where cycles are impossible. Erlang is a prime example. Region inference is another strategy in this space. It can limit the need for full-blown garbage collection in many cases, but also comes with its own set of added trade-offs. Reference counting is just a different kind of garbage collection, really. It acts like a dual construction to a tracing GC in many cases. If you start…
yeah one of the most helpful realizations I’ve read is that tracing and ref counting are essentially two formulations of the same problem - one is finding objects that are alive (by tracing), and the other is finding things that are dead (i.e. their ref counts reach zero). and of course, every object is either dead or alive!
Re: Fundamentals of garbage collection (2023)
#26Kindof unrelated to the article, but I was recently wondering if it would be possible to detect and deny pointer cycles in a language in an efficient way, so that you could then use simple reference counting instead of full-blown garbage collection. It probably wouldn't be usable for a general-purpose programming language, but for a special-purpose scripting language I could see it making the language implementation…
One solution is to forbid recursive data types - e.g., require every struct type to only reference types that have already been defined. I can't think of any languages that do this. Another solution is to make things immutable (like Erlang), or "as-if" immutable (like Koka), which guarantees that data can only point to things that have already been defined, preventing cycles.* Erlang uses this to simplify generationa…
Re: Fundamentals of garbage collection (2023)
#27Earlier quoted context omitted.
One solution is to forbid recursive data types - e.g., require every struct type to only reference types that have already been defined. I can't think of any languages that do this. Another solution is to make things immutable (like Erlang), or "as-if" immutable (like Koka), which guarantees that data can only point to things that have already been defined, preventing cycles.* Erlang uses this to simplify generationa…
Couldn't you make lazily evaluated code in erlang too, even if it's not lazy by default like Haskell? You'd just need function pointers, right? Or is that not enough?
-- circular linked list with one item
repeat x = let xs = x:xs in xs
Here's a rough equivalent in JavaScript that doesn't use thunks, just functions: function repeat(x) {
function xs() {
return [x, xs]; // [first, rest]
}
return xs;
}
The Haskell version has a cycle because, after evaluation, `repeat x` will be a circular linked list, but all the "lists" we create in the JavaScript code above are just the closure `xs`.For completeness, here's a JavaScript version that uses thunks:
class Thunk {
constructor(f) { this.f = f; }
get() { if (this.f) { this.v = (this.f)(); delete this.f; } return this.v; }
}
function repeat(x) {
let xs = new Thunk(() => {
return [x, xs]; // [first, rest]
});
return xs;
}
If you try calling `x = repeat(1); x.get()`, you can see that we get a circular list.Re: Fundamentals of garbage collection (2023)
#28Question: does anyone run "Server GC" for the ASP.NET applications? There is bunch of people copy pasting documentation to SO "explaining" server GC. I am running bunch of .NET stuff in VMs and never set "Server GC" and never ran into issues with default but also not sure if it is worth testing out. I guess it does not matter much if you are running in containers but I am running on VMs in IIS.
Server GC is a tradeoff between latency and throughput. It makes a ton of sense for a web server where a small additional overhead of a few milliseconds on some responses won't matter. Workstation GC is what you want when latency is critical. This is what you'd use if you were developing a UI or game engine. I've seen workstation GC stay in the microsecond region when strategically executing GC.Collect at allocation…
Do you have anything like running a business line application for couple of years on Server GC to write about?
Re: Fundamentals of garbage collection (2023)
#29Question: does anyone run "Server GC" for the ASP.NET applications? There is bunch of people copy pasting documentation to SO "explaining" server GC. I am running bunch of .NET stuff in VMs and never set "Server GC" and never ran into issues with default but also not sure if it is worth testing out. I guess it does not matter much if you are running in containers but I am running on VMs in IIS.
Server GC is the default garbage collector for Asp.net Core. > https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetco...
Re: Fundamentals of garbage collection (2023)
#30Earlier quoted context omitted.
You can make a programming language where cycles are impossible. Erlang is a prime example. Region inference is another strategy in this space. It can limit the need for full-blown garbage collection in many cases, but also comes with its own set of added trade-offs. Reference counting is just a different kind of garbage collection, really. It acts like a dual construction to a tracing GC in many cases. If you start…
> It acts like a dual construction to a tracing GC in many cases yeah one of the most helpful realizations I’ve read is that tracing and ref counting are essentially two formulations of the same problem - one is finding objects that are alive (by tracing), and the other is finding things that are dead (i.e. their ref counts reach zero). and of course, every object is either dead or alive!