Live data from Hacker News

Fundamentals of garbage collection (2023)

learn.microsoft.com

21–30 of 34 posts

Re: Fundamentals of garbage collection (2023)

#21

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…

[deleted]

Re: Fundamentals of garbage collection (2023)

#22

Earlier 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.

The talk for this paper came up on YouTube just the other day: https://www.youtube.com/watch?v=GwXjydSQjD8

Re: Fundamentals of garbage collection (2023)

#23
post #4

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…

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.

That would still be tracing. The problem is that if there is a cycle, the reference count would be too high, and you'd not detect that the object should be reclaimed.

Re: Fundamentals of garbage collection (2023)

#24

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…

Like Rust if it has no Rc?

Rc is implemented in Rust so it would be possible to create an equivalent in your own code.

Re: Fundamentals of garbage collection (2023)

#25
post #18

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…

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!

Re: Fundamentals of garbage collection (2023)

#26
post #5

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…

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?

Re: Fundamentals of garbage collection (2023)

#27
post #26
post #5

Earlier 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?

Haskell can have circular references because its laziness is implemented with thunks, which have a mutable cell in which to store the computed value so that terms don't get evaluated more than once. Here's a Haskell function that makes a circular linked list:

    -- 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)

#28
post #11
post #8

Question: 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…

Well great but you did not write out anything more than I could understand as a 15+ years developer of C#/.Net from whatever all those people in Stack Overflow wrote.

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)

#29
post #8

Question: 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...

Great one to see, definetly vote up!

Re: Fundamentals of garbage collection (2023)

#30
post #18

Earlier 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!

It's a useful realization but the follow on (unfortunately rather popular) claim that this inverse relation makes them the same thing is clearly wrong. They exhibit entirely different performance characteristics in places where it matters.
Post reply on HN